tunnuz has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks, I'm an Italian Computer Science student, and I'm trying to learn how to develop in Perl. In order to get experienced, these days, I'm trying to start a small project that happens to be a videogame in Perl that uses the SDL module (SDL_Perl).

Trying to configure SDL_Perl on various development machines (a Linux box, a Windows box and a MacOSX box) I found lots of troubles ...

The Linux box was the simpler one. I installed libsdl_perl via apt-get and then SDL via the CPAN shell. And all it's ok.
The Windows box gave me no results, but I have to admit that I didn't insist much.
The MacOSX box gave me lots of troubles, the libsdl-framework has to be installed via MacPorts (and it's not trivial), then it's the p5-sdl_perl time (and I can't still manage to install it).

And this all to configure my development machines!! How can I only think to deploy the application if it's going to see the light? Will the final user have to do all the work I did, to get the videogame up and running?

I never deployed an application, and maybe I'm focusing on a problem that doesn't exist, but I think that THIS side of Perl development should be improved ...

Replies are listed 'Best First'.
Re: Free thoughts about Perl development
by marto (Cardinal) on Aug 10, 2007 at 08:31 UTC
    Regards Windows I would suggest you take a look at, you may want to look at using CamelPack or Strawberry Perl rather than the base install from ActiveState. What problems are you having with the Mac, if you don't give us details we can't really help :)

    "Will the final user have to do all the work I did, to get the videogame up and running?"

    You may want to look at PAR regards packaging your game and prerequisite Perl modules (and data files).

    You may be interested to check out Frozen Bubble for an example of a 'popular' game written in Perl.



      The problems with the Mac are mainly linked to the MacPorts ports install system, one of the dependencies (libsdl_image-framework) fails to build and so the p5-sdl_perl package (the one I need) doesn't build too. The libsdl-framework package too needs some hacks to build.

      As I said I'm quite newbie to Perl, so my experience with PAR is only restricted to simple scripts packaging. Thought as far as I know, PAR isn't able to package the SDL library files together with the Perl program, and I had troubles packaging some simple Perl programs too (i.e. a Perl POE IRC bot I wrote for fun/learning).

      In Windows probably a tool to include the SDL libraries with the program distribution exists, but as I said, I didn't played too much on Windows/Perl.

      My question is: if I manage to run the game on Mac OS X, is it possible to include the SDL libraries in the package so that a final user only has to run the game (PAR packed, maybe).

      You may be interested to check out Frozen Bubble for an example of a 'popular' game written in Perl.
      Sooooo much productivity lost due to that awesome little game.

      I have nightmares with that French hip hop playing in the background ;)


Re: Free thoughts about Perl development
by chromatic (Archbishop) on Aug 10, 2007 at 05:49 UTC

    I did quite a bit of work on the SDL Perl build system a couple of years ago, and had next to no help from anyone who used either Windows or Mac OS X. Thus, it's no surprise that it's difficult to install on either operating system. I conclude that it will always be difficult to build and install software on a platform for which no one who uses that platform cares to fix the installer.

Re: Free thoughts about Perl development
by GrandFather (Saint) on Aug 10, 2007 at 01:54 UTC

    For the Windows install use ActiveState's ActivePerl

    DWIM is Perl's answer to Gödel
Re: Free thoughts about Perl development
by Moron (Curate) on Aug 10, 2007 at 09:10 UTC
    apt_get works under either Fedora or Debian is an rpm binary installation method.

    But Mac OSX does not support apt or rpm as far as I am aware. It is therefore easiest if every dependency is achieved via a tarball source installation that uses make to compile and install from sources.

    Make sure that each component uses the right basic library root i.e. if OSX has everything preinstalled in /usr/local/lib then before doing a make install of a component, check that it's going to go to the right place. But generally, if all the products are done by tarball then they tend to agree with each other just as if everything is done with apt and rpm they will also agree with each other. The only proviso is that it also has to agree with how the libraries are preinstalled for Mac OSX.

    Windows doesn't have a consistent library architecture - in spite of some common directories for DLLs there just isn't the adherence in general so I'd be inclined to reject Windows as infeasible.


    ^M Free your mind!

      Windows has a very consistent way of placing DLLs - just place them in the same directory as your executable program, in this case, perl.exe.

        The OP has multiple interdependent installations - to get results he therefore needs a common library architecture.

        So your comment about DLLs being local to a software component SUPPORTS my somewhat tentative accusation that Windows doesn't have it.

        Update: To clarify, it might be theoretically possible to put shortcuts to or copies of all relevant DLLS in different places - but what is theoretically possible isn't nearly as strong as saying something is "feasible", especially if you think through properly all the nasty obstacles that could appear such as an undocumented DLL filename not being present for a component. The OPs successful effort succeeded in an rpm environment that manages dependencies properly - it should ring the right alarm bells if you consider the implication that it didn't work in environments where dependencies were not managed.


        ^M Free your mind!

Re: Free thoughts about Perl development
by shotgunefx (Parson) on Aug 10, 2007 at 17:10 UTC
    As others have mentioned, Frozen Bobble would be a good place to look for an example of distribution.

    I *think* the SVN version of SDL_Perl have improved OSX functionality, not really sure as the upgrade to the module had the side effect of it failing to install on my linux boxes and as far as I know, wasn't fixed, so I stopped paying attention.

    I've kind of given up on SDL_Perl, I plugged a bunch of leaks, added a couple of mixer functions and sent it off, in December of 2006. Still waiting for them to be included. Since they haven't been, and every update seems to break something, helping with development seems to be a waste of time for me.

    I've just been tweaking my own branch since. If I had more time, I think I'd just roll my own with wxSDL, but I don't.

    "To be civilized is to deny one's nature."
      The problem wasn't SDL_Perl, but libsdl, but now I managed to install it thanks to the gentle MacPorts developers and maintainers :)2
      Tommaso "tunnuz" Urli Italian CS Student and Perl Newbie