Re: Building on Win32 - the real problem

On 31-Aug-09, at 12:43 PM, David Goehrig <[email protected]> wrote:

> On Mon, Aug 31, 2009 at 11:54 AM, Kartik
> Thakore<[email protected]> wrote:
>
>> What if this was fixed with Alien::SDL as it is doing for windows  
>> now? Kmx
>> is also working on strawberry compatible makefiles. This way we can  
>> compile
>> for most platforms from scratch.
>
> The problem is as Andreas originally pointed out that there are a
> metric ton of SDL_* dlls out there, not all of which are easily found
> in a readily accessible form for Windows.  There are other issues with
> Perl on Windows, regarding thread support, conflicts between Perl
> threads, Windows threads, and SDL threads, but these issues are more
> black magic stuff that really should only interest those of us hacking
> the guts of the system.
>
Right.
> Alien::SDL doesn't necessarily solve your problem on this front as
> what a Windows user / casual developer actually needs is a
> click-wrapped installer that provides all of the necessary SDL_* dlls
> and does not assume that they have a compiler in place.
>
But it does solve dev env setup for the developer.
> What I was working on 3 years ago, and never got finished for various
> reasons was a Linux/BSD/MacOSX/Win32 binary distribution complete with
> installer, desktop icons, and mime-type associations.  Hence the one
> version of the code with .spl or .sdlpl file endings.  This would go a
> long way towards solving the real problem, as sdlperl should be a
> separate application like wxperl is.  I have code for this under
> MacOSX, and I've done versions for Linux, but I've never built a
> windows version.
>
This is end user I agree we need this. But for now if we can get at  
least some one developing on sdl perl that's good. How the developers  
provide easy installs is up to them for now. What we can to is provide  
(v3.0) SDL::Package which will package their app/game into an easy to  
install pacakage.
> I'd recommend against focusing on playing nicely with CPAN, and focus
> on what the end user actually needs.
>
Again atleast we get code out there. CPAN is an easy install for the  
most part. Moreover this is a library not an end user app, I don't  
think holding back code is warranted.
>> Is prompting recommended in CPAN?
>
> Nope..  in general you don't want to prompt people in a CPAN friendly
> module.  There's a -y option, to auto say yes, but then you need to
> phrase your questions the right way :)
>
>> However some of these deps are not even used right now. Like vnc  
>> and svg.
>
> By your software you mean :)
>
> There aren't OO modules for this, but I have used the C-API calls
> directly.  I just haven't had time to roll a user friendly OO module
> for these things.  If someone would like to contribute one, be my
> guest please!
>
But my question is why do we need svg and vnc. Isn't better to focus  
on core sdl libs first?
>> Shouldn't distro distro specific be up to package maintainers of the
>> platform. For example one kmx's build scripts are ready Alias or  
>> CSJewell
>> will take over strawberry's packaging.
>
> Well the question is one of "will my app run on x"
> and if you give
> distro rollers an option, they will always do what is easiest for them
> to roll.  If you make it easy to roll the kitchen sink, they'll roll
> that, and it will come pre-installed that way on everyone using that
> platform.  If a distro can't load something for legal reasons, say
> SMPEG, then they can push out sdl-perl --deactivate=smpeg, and that
> just means that foonix won't support SMPEG by default.
>
> The real solution is of course, for us to distribute a binary Win32
> app with installer and use perl's ability to include arbitrary @INC
> paths to our libs.  It avoid the whole hoary mess, and ensures that
> people can distribute games without having to rely upon the user
> having some particular perl port installed.
>
I agree to this. But we need people to use our code and generate bug  
reports now rather then later. Hence CPAN.
> This is not just a windows problem BTW, on my macs for example I have
> 3 copies of perl5 installed.  /usr/bin/perl, /opt/local/perl and
> /usr/local/bin/perl.  I can't tell you how many times I've thought
> something was broken, when the wrong perl was running, or the wrong
> module path was included.
>
> For sdl-perl 3.0 I'd really like to see ...
>
Or something that makes a flat binary installer for what ever platform  
they need.
> Dave
>
> -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

Kartik