[Pipmak-Devel] The Pipmak Make setup for Linux

[Aidan G. <wgs...@ih...>]

Hello,

  Ok, I have.. more than "tweaked" the Pipmak Makefile for building on Linux,
and here's how it works...

  Note: Skip step 1 if you're going to use your system-wide shared libraries,
but it still links to Lua statically so you still have to compile Lua.

  Step 1: Compile libogg, libvorbis, physfs, and
openal with the --disable-static option passed to the configure script.

  Step 2: Compile Lua.  (Its make system is different from most libraries,
and doesn't have the option to disable shared libraries.)

  Step 3: Move or symolically link each of those libraries to
pipmak/build-linux, truncating the version number from the directory name.
Example:
ln -s /path/to/libvorbis-1.2.0 build-linux/libvorbis
OR
mv /path/to/libvorbis-1.2.0 build-linux/libvorbis

  Step 4: Now if you're building for the official tarball release, just type
make version=x.y.z release
as before.  But if you want to build Pipmak from source for yourself, using
your system-wide shared libraries, then you will need to comment and uncomment
a few lines in the Makefile.  The lines are clearly marked.  After that, run
make, and it will build Pipmak against your system-wide libraries (assuming
you have installed them correctly).

  What actually happens when you run "make version=x.y.z release" is (in
addition to what it did with the original Makefile) is copies the shared
object files for the libraries it needs to pipmak-x.y.z/libs/ and copies a
wrapper script to pipmak-x.y.z/pipmak and the actual Pipmak binary is named
pipmak-bin.  The wrapper script (just a shell script) sets the LD_LIBRARY_PATH
environment variable to look in the libs folder that was created earlier, and
executes pipmak-bin.

  However, I still left it so that it links to Lua statically, not because I
think it an uncommon library, but because we will want Pipmak to be using a
properly configured build of Lua (right?).  For example I found that it
doesn't enable loadlib by default in the configuration file.

  So why did I do it this way instead of linking to all of these libraries
statically?  Because (at least on my system, I haven't done extensive testing)
if the system already has the libraries installed system-wide, then those are
used instead of the .so files packaged with Pipmak, so a user, at their
option, can remove the .so files packaged with Pipmak, or replace them with
their own.  And after talking to some other Linux users, I understand that
when you try to link to several libraries statically, especially when some
libraries depend on others, you get into what some call dependency hell.
That's when you have to keep trying to resolve dependencies of dependencies,
until it's nearly impossible to figure out what it is that you're missing.
So the answer is, in short, because it's simpler.

  But what do all you other Pipmak users/developers think of this?

  -Aidan