80 lines
		
	
	
		
			4.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			80 lines
		
	
	
		
			4.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
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
 | 
						|
 | 
						|
HTML documentation is built from SGML sources via jw.  It is known to work
 | 
						|
with docbook-utils-0.6.9.  There is a problem with 0.6.10, which seems to
 | 
						|
have some messed up dsl files. If you have difficulty building the HTML
 | 
						|
documentation with your version of jw, then remove "doc" from the SUBDIRS
 | 
						|
list in the top-level Makefile and send a report of where the failure was to
 | 
						|
the gramps-devel list.  This distribution is tested with the style sheets
 | 
						|
and PNG support from the gnome-doc-tools-2-1 package.
 | 
						|
 | 
						|
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.1.4 should in
 | 
						|
principle work, v. > 0.2 should see no problems.  
 | 
						|
 | 
						|
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. 
 |