On Tue, 9 Dec 2003, Sebastian V=F6cking had this to say:
>I have some trouble building the newest CVS version.
>When 'make' comes to the newly created doc/gramps-manual/de directory,
>Making all in de
>make: Entering directory
>A little research shows that this Makefile doesn't exist because
>'./configure' doesn't create it:
>A little bit a playing with automake and autoconf fixed it then but now
>cvs is bugging me with modified Makefile.in files. That's ugly so
>someone should fix it. But I don't exactly know how this automake stuff
>works. So I won't change anything on these files.
Alex gave a pretty decent response regarding running the autogen.sh file.=
Basically, checking the README directs you to please read the INSTALL fil=
if building from source. That file provides the autogen.sh hint.
I'll try to provide a bit more info as we seem to be getting a few new=20
people to the bleeding edge. :)
In a nutshell, the basic dependencies are set forth in the *.am files (am
is the AutoMake extension). Invoking 'automake' processes these *.am
files to create *.in files. One of these is 'configure.in'. We then nee=
to run 'autoconf' to create an executable configure script from that
template. Once we have an up-to-date configure script, we can run it to=20
further produce the final files (e.g. Makefile from Makefile.in etc.) for=
our particular distribution. =20
Thanks to the wonders of 'make', it knows that if a particular .am file=20
has been modified, it must start over and rerun automake and friends from=
the beginning. Sometimes this causes problems when things aren't=20
perfectly in sync. The 'autogen.sh' file is a semi-convenient way of=20
sweeping these issues under the rug and automagically getting everything=20
up to date properly.
As for issues with conflicting Makefile.in files, again this is taken car=
of by the autogen.sh script. Unfortunately, there is no clean way to=20
use the *.in files with CVS because every time a developer runs=20
'configure' these files are 'updated' and thus would be in need of cvs=20
committing. However, each developer has his own system (RH, MDK, DEB,=20
SusE(?)) with his own set of tools and libraries. So, even if we _did_=20
commit the *.in files, they would be irrelevant to most other developers.=
It's a problem.
Finally, here's a hint for using CVS effectively. You can have a ~/.cvsr=
file that holds options that you want for any given cvs command. For=20
instance, mine contains the following:
update -d -P
so that by default any cvs command will get the -z3 flag for better=20
compression/transmission, 'cvs update' always gets the -d and -P flags (-=
prunes any directories that are empty after an update). This all happens=
without me having to even think about it anymore. :)
Donald A. Peterson | dpeterson@...
Ph.D. Research Associate |=20
Dept. of Chemistry | PH: (541) 737-7079
Oregon St. University | FAX: (541) 737-0480