Next: Scheme API reference, Previous: General design, Up: Top
Yes, using deep build tree (up to 7 levels) with make is not recommended when one seeks performance and wishes to have a program built as fast as possible.
Doing so, and including a generated Makefile in every single
directory, even in ./data
might sound stupid. But... it's
in the long run easier to do this and use all the automatic
packaging and depoyement strategic of a genuine ./configure
script, than writing one's own install script, which will
without any doubt end up with a broken unsinstall
target,
and so on.
In addition to all the common
Autoconf switches
such as --prefix
, Liquid War 6 has some custom switches:
--enable-allinone
: will stuff all the convience libraries
and in a general manner everything that sounds like C code
and is in Liquid War 6 source tree into one big executable.
Very convenient for profiling. The major drawback is that
you need to have all the optional libraries installed
to compile all the optional modules.
--enable-fullstatic
: will build a totally static
binary, that is using the --static
option
for gcc
and the -all-static
option
for libtool
. Currently broken, this option could
in the future allow for building binaries that run
pretty much everywhere, without requiring any dependency
but a Kernel.
--enable-gprof
: will enable profiling informations.
Note that it is recommended to use --enable-allinone
too, or else you will only track the time spent in functions
in the main liquidwar6
executable. As there are
very few of them, it's totally uninteresting.
--enable-valgrind
: will enable some CFLAGS
options which are suitable for the use of
Valgrind, to track
down memory leaks and other common programming errors.
Use for debugging only, usually together with
--enable-allinone
.
Liquid War 6 comes with a ./debian
subdirectory,
which allows for creation of vendor .deb
binaries.
The files generated have an explicit vendor
suffix,
which identifies them as being the files generated
from the original source tarball.
In the future, the Debian
project, or any GNU/Linux distribution which relies on
.deb
packages, might decide to (re)package Liquid War 6 and
implement its various packaging policies, but this is another
subject.
Liquid War 6 is splitted into several .deb
packages:
liquidwar6
: the main package. Should pull all the
required packages through dependencies.
liquidwar6-data
:
Data for Liquid War 6. Contains maps, but also the main
program which is composed of platform independant script files.
libliquidwar6
:
This is the core engine for liquidwar6.
libliquidwar6-devel
:
Headers and static libraries for liquidwar6. Also contains a test
suite which allows testing of individual libraries.
libliquidwar6-mod-gl
:
An SDL/OpenGL accelerated renderer for Liquid War 6.
libliquidwar6-mod-gl-data
:
Data for Liquid War 6 mod-gl, mostly graphics.
libliquidwar6-mod-gl-devel
:
Headers and static libraries for Liquid War 6 mod-gl.
libliquidwar6-mod-ogg
:
An Ogg/Vorbis sound engine for Liquid War 6.
libliquidwar6-mod-ogg-data
:
Data for Liquid War 6 mod-ogg, mostly sounds and musics.
libliquidwar6-mod-ogg-devel
:
Headers and static libraries for Liquid War 6 mod-ogg.
A typical end-user installation will use packages:
liquidwar6
liquidwar6-data
libliquidwar6
liquidwar6-mod-gl
liquidwar6-mod-gl-data
liquidwar6-mod-ogg
liquidwar6-mod-ogg-data
One important thing to note, and which very certainly violates the
Debian policies,
is that the documentation is provided in the main package, which
is platform dependent. Doing so is the best way to ensure
that everybody has the documentation, even those who use --force
switches. It does waste a little disk space, but this is nothing
compared to the overall disk usage of a package like Liquid War 6.
Liquid War 6 comes with a .spec
file,
which allows for creation of vendor RPM
binaries.
The files generated have an explicit vendor
suffix,
which identifies them as being the files generated
from the original source tarball.
In the future, the Red Hat,
or any GNU/Linux distribution which relies on
RPM
packages, might decide to (re)package Liquid War 6 and
implement its various packaging policies, but this is another
subject.
Liquid War 6 is contained in one jumbo RPM
package.
The reasons for not splitting it in several small packages
range from the limitations of RPM
itself, to the fact that having two different packaging
strategies implemented can be interesting in itself.
Note that Alien can be used to switch between various package formats.