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 ;)

-David.

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.

For the Windows install use ActiveState's ActivePerl

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.

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!

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