Re: Building on Win32 - the real problem
-=-=- d...@nexttolast.com -=-=- On Sep 1, 2009, at 8:56 AM, Guillaume Cottenceau gcott...@gmail.com wrote: or urpmi :) I know, I know, mandriva is just not hype anymore.. Was it ever :) Thanks. Well, I can't remember how I first tried sdl-perl. I surely don't like/use cpan a lot, so I am not sure if it wasn't packaged as an RPM in mandriva before I started developing FB. But surely what I remember is that I spotted a few bugs in sdl-perl when developing FB :) That was back when I was at VA Linux and was using CVS at sourceforge for all my hosting. I bet if I could find out because that was pre- Tels everything is a scalar ref patch :) When did we get old? Dave
Re: Building on Win32 - the real problem
Thanks. Well, I can't remember how I first tried sdl-perl. I surely don't like/use cpan a lot, so I am not sure if it wasn't packaged as an RPM in mandriva before I started developing FB. But surely what I remember is that I spotted a few bugs in sdl-perl when developing FB :) If you remember or can find them some of the bugs. Can you post them onto RT? Oh, I talked about the bugs in sdlperl 1.x, they were fixed looong ago already :) -- Guillaume Cottenceau - http://zarb.org/~gc/
Re: Building on Win32 - the real problem
-=-=- d...@nexttolast.com -=-=- On Sep 1, 2009, at 9:25 AM, Kartik Thakore thakore.kar...@gmail.com wrote: If you remember or can find them some of the bugs. Can you post them onto RT? If Guillaume can remember a single bug from those days without looking it up I'll buy him a beer next time I'm on the Continent. :)
Re: Building on Win32 - the real problem
On Tuesday 01 September 2009 05:49:50 David Goehrig wrote: Sdl-perl has been in cpan for 9 years and that hasn't helped much. I believe that has more to do with the fact that it's nearly impossible to install SDL_perl from the CPAN due to its packaging and dependencies more than anything else (and I'll take due blame for the last couple of years of that). -- c
Re: Building on Win32 - the real problem
Okay I was planning on hacking XS today (http://yapgh.blogspot.com) but David makes a lot of good comments. On 31-Aug-09, at 9:17 AM, David Goehrig d...@nexttolast.com wrote: Ages ago all of the xs code was broken out into separated files. We switched over to a monolithic build with conditional compilation due to the problems of maintaining coherency in the face of nested dependencies. 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. One of the things the old build scripts did that the new pseudo-cpan- friendly ones do not was it prompted you as to what would be built and gave you an option to fix the dependencies. Is prompting recommended in CPAN? Since some SDL addons require other SDL addons it is important to make sure you link against the same versions of each Lib. I would argue the correct solution is to require all deps by default with an option not to load at run time. The reason to this is when packaging a distro you want a standard package to build against. Hence the kitchen sink approach. However some of these deps are not even used right now. Like vnc and svg. If I apt-get sdl-perl I would want the full install. If I'm engineering a resource constrained device I am already assuming enough effort to make making a cut down build worth my while. At which point the monolithic should still just work. 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. I personally perfer to make design decisions that meet the needs of the 90% of users who are just expecting it to just work. The other 10% you can never please anyways :) Agreed. But there is only so much I can do for packaging. Dave Ps we by definiton are in that 10%. So our opnions don't count. -=-=- d...@nexttolast.com -=-=- On Aug 30, 2009, at 4:48 PM, chromatic chroma...@wgz.org wrote: On Sunday 30 August 2009 00:45:15 Andreas Lund wrote: Yet again I have decided to try building SDL on Win32 and yet again I have not even made it to the actual building. Why? Because only about half the required libraries can be downloaded for Windows. That brings up a good point. SDL_perl 2.x builds a monolithic XS which attempts to link against plenty of SDL-related libraries, such as SDL_ttf and SDL_gfx. Even though distribution becomes slightly more complex, I suggest that SDL_perl 3.x build separate XS files for these supplementary libraries. Perhaps they could even be separate CPAN distributions. It might be worth considering something similar for the OpenGL components as well. -- c
Re: Building on Win32 - the real problem
On Mon, Aug 31, 2009 at 11:54 AM, Kartik Thakorethakore.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/
Building on Win32 - the real problem
Yet again I have decided to try building SDL on Win32 and yet again I have not even made it to the actual building. Why? Because only about half the required libraries can be downloaded for Windows. smpeg-0.4.5 The SDL webpage refers to http://www.icculus.org/smpeg/ which states the following: You can check out smpeg from Subversion via these simple instructions: svn co svn://svn.icculus.org/smpeg/trunk smpeg Unfortunately, there are two problems here. First of all, the 'svn' command is meaningless to anyone not familiar with Subversion. Secondly, even those who know what Subversion is and actually manage to download and install a client and check out the files... the only thing you will get is the source code, not the Win32 library. If you don't know how to compile it, you're out of luck. SDL_sound The SDL webpage refers to http://icculus.org/SDL_sound/ Now, just in case anyone actually succeeded in getting past Subversion, they decided to use Mercurial for this: To download SDL_sound via Mercurial: hg clone http://hg.icculus.org/icculus/SDL_sound/ ...or, for the stable (non-development) branch: hg clone -r stable-1.0 http://hg.icculus.org/icculus/SDL_sound/ And ofcourse, you'll still only get the source code, not the Win32 library. SDL_gfx The SDL webpage refers to http://www.ferzkopp.net/joomla/content/view/19/14/ How refreshing to actually see a tarball ready for download. Ofcourse, most perl devs know how to extract one, but again... this is the source code only, not the actual library. SDL_svg The SDL webpage refers to http://www.linuxmotors.com/SDL_svg Actually managed to get stuff compiled for the other libs? Well okay, try to get past this then... this time you only get to download the linux library, not the source code. Muahahaha! SDL_vnc The SDL webpage refers to http://www.ferzkopp.net/~aschiffler/Software/SDL_vnc/index.html which is a broken link. Still don't give up do you? OK so you navigate the site, and again you find a tarball with source code only. Until these hurdles are solved, the number of people both willing and able to TEST SDL-Perl on Windows will remain stable at near zero, and the irregular attempts to resurrect the project are almost guaranteed to fail. -- Andreas Lund (fl...@atc.no) Tel: +47 90077162 #include disclaimer.h Look at you hacker, panting and sweating as you run through my corridors. How can you challenge a perfect immortal machine? -- SHODAN, System Shock
Re: Building on Win32 - the real problem
Hi, Andreas which version of SDL perl did you try for windows? If you would have gotten v2.2.2.5 (sorry for the stupid version names), it would have required Alien::SDL v0.02 which should have gotten the bare minimum of deps needed on windows. Moving on, On 30-Aug-09, at 3:45 AM, Andreas Lund fl...@atc.no wrote: Yet again I have decided to try building SDL on Win32 and yet again I have not even made it to the actual building. What failed in building? Why? Because only about half the required libraries can be downloaded for Windows. Some of these deps are not required. smpeg-0.4.5 The SDL webpage refers to http://www.icculus.org/smpeg/ which states the following: You can check out smpeg from Subversion via these simple instructions: svn co svn://svn.icculus.org/smpeg/trunk smpeg Unfortunately, there are two problems here. First of all, the 'svn' command is meaningless to anyone not familiar with Subversion. Secondly, even those who know what Subversion is and actually manage to download and install a client and check out the files... the only thing you will get is the source code, not the Win32 library. If you don't know how to compile it, you're out of luck. This is downloaded for you with Alien::SDL SDL_sound The SDL webpage refers to http://icculus.org/SDL_sound/ Now, just in case anyone actually succeeded in getting past Subversion, they decided to use Mercurial for this: To download SDL_sound via Mercurial: hg clone http://hg.icculus.org/icculus/SDL_sound/ ...or, for the stable (non-development) branch: hg clone -r stable-1.0 http://hg.icculus.org/icculus/SDL_sound/ And ofcourse, you'll still only get the source code, not the Win32 library. This library I haven't gotten around to make for windows. SDL_gfx The SDL webpage refers to http://www.ferzkopp.net/joomla/content/view/19/14/ How refreshing to actually see a tarball ready for download. Ofcourse, most perl devs know how to extract one, but again... this is the source code only, not the actual library. Same as above. SDL_svg The SDL webpage refers to http://www.linuxmotors.com/SDL_svg Actually managed to get stuff compiled for the other libs? Well okay, try to get past this then... this time you only get to download the linux library, not the source code. Muahahaha! This dep is not actually used (I haven't seen thing wrong with not having it). If you are seeing error messages please post a bug report. SDL_vnc The SDL webpage refers to http://www.ferzkopp.net/~aschiffler/Software/SDL_vnc/index.html which is a broken link. Still don't give up do you? OK so you navigate the site, and again you find a tarball with source code only. Same as above. Until these hurdles are solved, the number of people both willing and able to TEST SDL-Perl on Windows will remain stable at near zero, and the irregular attempts to resurrect the project are almost guaranteed to fail. Thanks for the vote of confidence. -- Andreas Lund (fl...@atc.no) Tel: +47 90077162 #include disclaimer.h Look at you hacker, panting and sweating as you run through my corridors. How can you challenge a perfect immortal machine? -- SHODAN, System Shock
Re: Building on Win32 - the real problem
Oh forgot to mention ... Alien::SDL will extract the deps to C:/ strawberry/ . So if you strawberry is installed some place else it may not work. Kartik Thakore On 30-Aug-09, at 3:45 AM, Andreas Lund fl...@atc.no wrote: Yet again I have decided to try building SDL on Win32 and yet again I have not even made it to the actual building. Why? Because only about half the required libraries can be downloaded for Windows. smpeg-0.4.5 The SDL webpage refers to http://www.icculus.org/smpeg/ which states the following: You can check out smpeg from Subversion via these simple instructions: svn co svn://svn.icculus.org/smpeg/trunk smpeg Unfortunately, there are two problems here. First of all, the 'svn' command is meaningless to anyone not familiar with Subversion. Secondly, even those who know what Subversion is and actually manage to download and install a client and check out the files... the only thing you will get is the source code, not the Win32 library. If you don't know how to compile it, you're out of luck. SDL_sound The SDL webpage refers to http://icculus.org/SDL_sound/ Now, just in case anyone actually succeeded in getting past Subversion, they decided to use Mercurial for this: To download SDL_sound via Mercurial: hg clone http://hg.icculus.org/icculus/SDL_sound/ ...or, for the stable (non-development) branch: hg clone -r stable-1.0 http://hg.icculus.org/icculus/SDL_sound/ And ofcourse, you'll still only get the source code, not the Win32 library. SDL_gfx The SDL webpage refers to http://www.ferzkopp.net/joomla/content/view/19/14/ How refreshing to actually see a tarball ready for download. Ofcourse, most perl devs know how to extract one, but again... this is the source code only, not the actual library. SDL_svg The SDL webpage refers to http://www.linuxmotors.com/SDL_svg Actually managed to get stuff compiled for the other libs? Well okay, try to get past this then... this time you only get to download the linux library, not the source code. Muahahaha! SDL_vnc The SDL webpage refers to http://www.ferzkopp.net/~aschiffler/Software/SDL_vnc/index.html which is a broken link. Still don't give up do you? OK so you navigate the site, and again you find a tarball with source code only. Until these hurdles are solved, the number of people both willing and able to TEST SDL-Perl on Windows will remain stable at near zero, and the irregular attempts to resurrect the project are almost guaranteed to fail. -- Andreas Lund (fl...@atc.no) Tel: +47 90077162 #include disclaimer.h Look at you hacker, panting and sweating as you run through my corridors. How can you challenge a perfect immortal machine? -- SHODAN, System Shock
