Table of Contents

1) Required software
2) automake/autoconf notes
3) which does what
4) building code

***************************

1) Software required for developers:

In order to compile lifelines from the cvs sources,
the developer needs to have a number of tools available.

make: build process requires gmake
autotools suite: both autoconf and automake (which in turn 
     require the m4 macro processor) are used to generate
     Makefiles and various build files.
bison: Is required to compile lifelines/src/interp/yacc.y.
m4: Is required by the autotools suite as well as for
    generation of the default lifelines configuration 
    prototypes.
perl: Is required to generate the file index.html in the
   reports directory, as well as for generation of lines.cfg.
jw: Is used to compile the documentation.  It is at least 
   available in the debian text/docbook-utils package
   and the Redhat docbook-utils package. Lack of this tool
   is not critical, however, and the make will continue,
   only listing these lacks as warnings.  The generated
   documention is included in both the cvs and src distributions.
   This will only prevent regeneration of the documention.
jadetex: Is used to produce pdf versions of the documentation.
   It is at least available in the Redhat jadetext package.
   See jw above.
lynx: Is used to compile text versions of documentation. See
   jw above.

Note: These requirements are for compiling from
the cvs sources, not from a distribution tarball.
Distribution tarballs are built so as not to require
autotools or bison.  However, m4 and perl are required.


***************************

2) Some notes about using automake/autoconf:

Many of the files you're used to editing by hand are automatically
generated by automake &/or autoconf.  These include any file named
Makefile, Makefile.in, config.h, config.h.in, or configure.

The proper files to modify by hand are configure.ac (if there's something
new you need to determine about the host system at configuration time)
and Makefile.am (if source files are added or removed, targets added,
or dependencies changed).

As long as you have autoconf and automake installed on your system, the
Makefiles generated will be able to regenerate any file dependent on a
Makefile.am or configure.ac.  To regenerate the build system explicitly,
 sh autogen.sh

The autogen script *must* be run after freshly checking a copy of the
project out of CVS -- the files generated automatically are no longer
included in the CVS repository.

I'm happy to help anyone who needs help adjusting the automake/autoconf
build system to suit your development needs...

Rob Fugina
robf@geekthing.com

(Perry added autogen.sh, 2002.06.04)


***************************

3) Which does what:

At development (or package creation) time, the autogen.sh script
will perform the following 4 steps for you:

1) aclocal: This generates aclocal.m4 from acinclude.m4.

For lifelines aclocal is invoked as 
  'aclocal -I m4 -I build/autotools'
in order to get all the autoconf, automake and gettext 
macros into aclocal.m4.

2) autoheader: This generates acconfig.h.

3) automake: This generates Makefile.in files from Makefile.am files.

4) autoconf: This generates configure from configure.ac.

On remote machine compiling a source distribution package:

configure will generate config.h and Makefile files from Makefile.in files.

4) Building the code

1. check out the code from cvs - there is a link off 
   http://lifelines.sourceforge.net
   which gives instructions for checking out the code.  If you're not a 
   sourceforge developer, you can use the anonymous checkout procedure.
2. For building, refer to the README.MAINTAINERS file and execute the
   commands under 'Run autotools:' and 'Build local copy in ./bld subdirectory:'
   Note: these commands describe one way to proceed.  There are many other
   approaches which will also work.
3. The language files po/*.po get updated when you build code; they are also
   updated from CVS.  If you find that conflicts occur with these files,
   you can simply remove them and update them from CVS again.  Then your build
   should proceed as normal.
4. curses.h.  It seems that every distribution places curses.h and
   libcurses.so in different places or has slightly different names 
   for the files.  For example, libcursesw.so or libcursesw.a seem the 
   most prominant versions.  If you find that lifelines can't find curses.h
   on your system, you can pass in the directory of the file on the configure
   step.  For example if your curses.h was in /usr/local/ncurses and it wasn't
   being found, you could add to the configure step
   ../configure CPPFLAGS=-I/usr/local/ncurses