<div class="blog">
<h1 id="NAME">
-More Games + Update
+The Build Process of SDL Perl
</h1>
<div class="CONTENT">
-<div style="text-align: right;"><i><br />idle digits,<br />play,<br />away,<br />idle digits.<br /></i></div><br />So while I am hacking away on v2.4 and <a href="http://github.com/kthakore/SDL_perl/tree/experimental">breaking</a> a lot of things. Here is a link to some more <a href="http://home.comcast.net/%7Eg.f.taylor/GarrysGames.html">games</a> for SDL Perl. These only work in windows now but I will look into bringing them to CPAN (with Garry's permission). <br /><br /><i>--yapgh</i><br /><br />These where reported by Garry Taylor. Here is the rest of the email:<br /><br /><blockquote><i>Hi all,</i><br /><i>I hadn't checked this newsgroup in a while and was happy to see </i><br /><i>that it still alive and well. I saw that some people had been sharing </i><br /><i>some SDL Perl games online, and I had a few to share as well. At </i><br /><i>"http://home.comcast.net/~g.f.taylor/GarrysGames.html" you can find four </i><br /><i>games I have written as well as a simple flip book program to let a </i><br /><i>child play at making animation on the computer. The games are "Toad" (a </i><br /><i>Frogger wanna be), "RabbitHat" (like Centipede), "BunnyHunt" (sort of </i><br /><i>like Pac-Man) and "Bonk The Buggies". All (with the exception of Toad </i><br /><i>which in its very first incarnation was a game I wrote in TRS-80 Basic </i><br /><i>back in 1981) were written originally to run on my Windows 3.11 PC for </i><br /><i>my little girl so that she could play games which were not quite so </i><br /><i>violent as games were starting to become at the time.</i><br /><i><br /></i><br /><i>A few years ago I got the idea of trying to get them to run again </i><br /><i>by rewriting them in Perl. The downloads are Windows XP/Vista installs </i><br /><i>which include a bare bones Perl environment for running the games (the </i><br /><i>installs put the code into its own separate place, and shouldn't </i><br /><i>interfere with your existing Perl setups). I did this so that I could </i><br /><i>share the games with friends and family who either don't have SDL </i><br /><i>installed, don't have Perl installed, or don't do any programming and </i><br /><i>just needed something that will run. The code as it currently stands </i><br /><i>was not written for general publication, so there are probably places </i><br /><i>where the Perl code itself is not always the best looking it could be, </i><br /><i>but the games themselves work pretty well. Also, it is worth noting </i><br /><i>that I wound up being lazy and made a few additions to the Perl SDL code </i><br /><i>that I was using to add an additional function or two for printing text </i><br /><i>onto the screen that was centered or right aligned.</i><br /><i><br /></i><br /><i>While I have not made any Unix installs for the code, I have </i><br /><i>actually run the games on a few Linux machines that I have access to, </i><br /><i>where I also had installed SDL. I have not updated my SDL installs in </i><br /><i>several years now, so there may be complications that arise if running </i><br /><i>it with a new version of SDL.</i><br /><i><br /></i><br /><i>I hope you enjoy the games (or at least aren't too mean about it </i><br /><i>if you don't).</i><br /><i>Garry Taylor</i></blockquote><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3102167581424744259-500220938152318100?l=yapgh.blogspot.com' alt='' /></div></div></div>
\ No newline at end of file
+<p>A while ago I had a long chat with mst on why SDL uses Module::Build rather then Make. I told him it is a simple matter of code inertia. The existing Module::Build system has worked well for us so far. Never the less, he convinced me that switching to Make will improve debugging the Build system. But to be able to switch we will need to completely replace the Build system. I am not prepared to do that so I will just present the requirements so mst or someone else can at least attempt to switch.</p><br />
+<br />
+<h3>The Build Process </h3><br />
+<b> Alien::SDL </b><br />
+<br />
+<p>SDL Perl depends on a few C libraries for a complete install. This is handled by Alien::SDL. First we look for existing SDL libraries and dependencies by doing a <a href="http://github.com/kthakore/Alien_SDL/blob/master/inc/My/Utility.pm#L581">File::Find</a> for headers. If these headers are found we present and option for the user to use those. We then store these locations in Alien::SDL->config options 'cflags', 'prefix' and 'libs'. If we do not have libraries available even for a minimum SDL installed ( SDL.h is not found). We provide several platform specific options. </p><br />
+<p>For windows we have a simpler process. We download<a href="http://github.com/kthakore/Alien_SDL/blob/master/inc/My/Utility.pm#L7"> prebuilt </a>binaries ( and checksum ) based on the user's selection and just copy them in to the right location. Again the 'prefix', 'cflags', and 'libs' is saved in Alien::SDL->config. </p><br />
+<p>For *nix/MacOSX we download sources and attempt to compile them. To be able to do this we download several other dependencies like libpng, jpeg and pango. You can see how we do this using hashes <a href="http://github.com/kthakore/Alien_SDL/blob/master/inc/My/Utility.pm#L404">here</a>. During the compile process we also apply patches as needed for the <a href="http://github.com/kthakore/Alien_SDL/blob/master/inc/My/Utility.pm#L430">sources</a>. Once this is done we can head to SDL Build.PL </p><br />
+<b> SDL Perl dependency resolution </b><br />
+<br />
+SDL's Build is responsible for linking the right libraries to the correct XS. If libraries are missing it will disable the component (not put it in SDL->config). <br />
+<br />
+<p>For example to build <a href="http://github.com/kthakore/SDL_perl/blob/master/Build.PL#L342">Image.xs</a> we require libsdl, libsdl_image and lib[jpg|png|tiff]. So we would check for these headers in the prefix provided by Alien::SDL->config. If they are not provided we will disable the SDL::Image module. </p><br />
+<p>More over the availability of each library is specified as a -DMACRO to the gcc compiler. This way we can prevent XS failures due to missing libraries using #DEFINES. Here the SDL_image macro is <a href="http://github.com/kthakore/SDL_perl/blob/master/Build.PL#L422">defined</a> and <a href="http://github.com/kthakore/SDL_perl/blob/master/src/Image.xs#L13">used</a>. The availability of the module is then available from <a href="http://github.com/kthakore/SDL_perl/blob/master/t/image.t#L20">SDL::Config->has()</a> <br />
+<br />
+<br />
+<b> Conclusion </b> <br />
+<p>This is a high level overview of our Build process, because frankly I hate traumatizing my brain with this again. Credits have to go to FROGGS and kmx for helping with this Build scheme. Hopefully my post have helped people at the very least appreciate the problem scope of this Build system. That said I believe a fresh written build system, with these requirements in mind, will be more then welcome.<br />
+</p><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/3102167581424744259-4514794130108689562?l=yapgh.blogspot.com' alt='' /></div>
+<p><a href="http://feedads.g.doubleclick.net/~a/SHI8waMCUMOT4LmhUSkV3-Y1cK8/0/da"><img src="http://feedads.g.doubleclick.net/~a/SHI8waMCUMOT4LmhUSkV3-Y1cK8/0/di" border="0" ismap="true"></img></a><br/>
+<a href="http://feedads.g.doubleclick.net/~a/SHI8waMCUMOT4LmhUSkV3-Y1cK8/1/da"><img src="http://feedads.g.doubleclick.net/~a/SHI8waMCUMOT4LmhUSkV3-Y1cK8/1/di" border="0" ismap="true"></img></a></p><img src="http://feeds.feedburner.com/~r/YetAnotherPerlGameHackeryapgh/~4/fTwVmM222rA" height="1" width="1"/></div></div>
\ No newline at end of file
projects / sdlgit/SDL-Site.git / blobdiff