#12 Proper configure and Makefile

[Anonymous]

Golly tries to find its data on the same dir where the
binary is. It makes difficult to do a proper
installation on Linux and packaging for distros.

It would be fine if you could provide a proper
configure script in order to configure prefix
installation and such.

[Tomas Rokicki]

Logged In: YES
user_id=1262668

Who posted this? If someone is considering adding golly to
a distribution---we'd be very delighted to do whatever is
needed. On the other hand, I have no experience (as a
developer) with configure and/or the requirements of "prefix
installation" so a little bit more detail would be very
helpful. Thanks!

[Dan Hoey]

Logged In: YES
user_id=1372332

I don't know who posted that, but I can explain the what and
why. The idea is that (especially on a multi-user system)
you want one copy of the executable, prepackaged data,
default preferences, and documentation (possibly in
different places) and one copy per user of preferences and
private data. The places are sometimes called prefixes.

Configure scripts provide a standard interface for supplying
the prefixes and build a header file that tells the program
where things are. There's also automatic detection of where
x11 and wxWidgets is installed and how the user gets the
compiler to provide 32-bit ints and pointers. When 64-bit
golly is provided (which is much more important than this)
it will also be necessary to determine how to get 64 bit
ints and pointers.

There's a tool called autoconf
(http://directory.fsf.org/devel/build/autoconf.html) to
produce shell scripts to do this sort of stuff on linux,
Mac, and Cygwin; I'm not sure if it does Windows in the
absence of Cygwin. I'm not an expert in how to do this
stuff, but it makes life easier for people who build and
install and update programs for the use of lots of people.

[Stefan O'Rear]

Logged In: YES
user_id=1520814

If you just want same quick background, the (*nix)
Filesystem Hierarchy Standard (http://www.pathname.com/fhs)
is good and has lots of useful rationales.

If you have more time (= a day or two) the Debian Policy
documents (http://www.debian.org/devel right hand menu) are
probably better. Debian calls them mandatory reading for
anyone intending to package software for Debian. (I don't
know how relevant they are for other Unix-like systems, but
it's probably similar if you ignore the little details.)