On Mon, Aug 31, 2009 at 11:54 AM, Kartik Thakore<thakore.kar...@gmail.com> 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. 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. 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. I'd recommend against focusing on playing nicely with CPAN, and focus on what the end user actually needs. > 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! > 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. 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 a flat binary installer, with an extras directory containing all the pre-req dlls for each platform, and a nice clean binary sdlperl which embeds perl, and provides a full graphical debugger. I did one of these about 5 years ago, and it was a lot of fun, but it never was released into the wild. But as with most things, there's only so many hours in the day :) Dave Dave -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
