gramps/gramps2/INSTALL

For rebuilding from source, here are some guidelines to follow.  For
developers who may be adding functionality to the program, be sure to read
the last section of this documen: "FINAL WORDS".

SUPER-SHORT VERSION:
You should be able to just run "./configure && make". But if you make any
significant changes or experience any problems, you may wish to run
"./autogen.sh && make" to regenerate everything.

This will call aclocal if necessary, then automake, which creates
Makefile.in from Makefile.am rules. Then it calls autoconf, which will
generate configure from configure.in and the Makefile.{am,in} sources.
Finally, autogen calls configure to generate the final files necessary for
building gramps.

SHORT VERSION:
Execute:
aclocal
automake --add-missing --gnu && autoconf && make

MORE INFO: Version and package info is now set in configure.in through a
call to the AM_INIT_AUTOMAKE macro.  The results are stored in variables
PACKAGE and VERSION, which then get substituted wherever necessary. 
(gramps.sh, gramps.spec, src/const.py, asst. Makefiles, etc.) We also
manually set the RELEASE variable for setting things like "pre" or minor
bugfix issues. * Note: Using @VERSION@ in the manuals has the advantage that
the current manual always states that it describes current version of
gramps.  The disadvantage is that this becomes misleading if the manual
isn't regularly updated.  Keep in mind this is GRAMPS version and not
*manual* version. Another problem is that the standard GNOME SGML
documentation make rules (sgmldocs.make) have their own rule, but automake
generates its own rule and this introduces a conflict.

"make (un)install" now runs scrollkeeper-update to ensure
documentation database is up to date. Scrollkeeper v. > 0.3 is required
to properly register documentation.

VERBOSE, UGLY DETAILS FOR DEVELOPERS:
Using automake/autoconf adds many, MANY build targets to the makefiles.
Basically, we only care about the main and "install" targets.  However,
there are some others that bear further notice:

* make dist -- will create a lovely gramps-{VERSION}.tar.gz archive with
everything needed to distribute, including the HTML documentation just in
case Joe User doen't know about or have a compatable jw/db2html.  After
running "make dist" you can create the  rpms using 
"rpm -ta gramps-{VERSION}.tar.gz".  How nice is that?

* make clean -- only gets rid of byte-compiled stuff like .so files.

* make distclean -- improves on clean by eliminating configuration (*.in,
config.*, Makefiles, and converted documentation.) stuff. This is generally
what you (as a developer) will want for testing "fresh" compiles.

* make trans -- We add this one on our own for building the template.po file.

Another caveat of the automake mantra is that new/overriding make
targets/rules/defines should generally go in the Makefile.am files rather
than Makefile.in.  

* Note: Another beauty of the automake mechanism (and having automake macros
in the configure script) is that once the scripts have been made, a change
to any .am file will trigger "make" to regenerate the Makefile.in/configure
scripts as appropriate.  It is _very_ convenient.

FINAL WORDS: automake "thinks" of a distribution in terms of "SOURCES", such
as raw C code, "COMPILED OBJECTS" like executables and libraries, and
"DATA", such as images, scripts, and documentation.  Thus, for gramps we
concentrate on DATA-type objects.  We must tell automake what objects are
important.  We do this by adding to the EXTRA_DIST variable in the various
Makefile.am files before running automake.