On 31-Aug-09, at 12:43 PM, David Goehrig <d...@nexttolast.com> wrote:
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.
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
