How would people feel if I moved gnucash to automake? Has anyone here
had bad experiences with it? In the past I've used it for smaller
projects with good results. I've already begun trial work converting
gnucash's make system over to automake and am so far quite happy with
the experience. Whenever I run into a problem, I dig around and find
that the automake folks have dealt with and solved the problem for me!
[For those who aren't familiar, automake's major purpose is to take
fairly small, standard and maintainable Makefile.am files and turn
them into full blown Makefile.in files that support the full set of
GNU makefile conventions. See http://sourceware.cygnus.com/automake/
for more.]
I'll mention now that a switch to automake makes sense only in the
context of my mail earlier this week. Namely, that we move to a
system where the gnome/motif/qt decision happens at ./configure time,
not make time. The motivation behind this is early detection of build
problems, thereby reducing gnucash compilation problems.
Assuming the above, we have a choice: (a) change the existing
Makefile.in's to work in the above manner or (b) use automake to make
the job easier.
The reason I began exploring option (b) was that I do not relish
mucking around with all the details involved with option (a).
Automake exists because I'm not the only one with the same feeling.
Anyway, the good things:
- It is mature -- nearly as mature as autoconf.
- It is widely used. GNU's tar and cpio packages use it. A good
number of Gnome apps use it. It is used by all of Cygnus' internal
development. The mailing list is active with questions.
- It is actively developed. After a few years lying fallow, Cygnus
has put full time developers on both autoconf and automake.
- It is being managed well. The package is evolving in sane,
backwards compatible, ways. The stable releases are actually
stable, etc.
- It simplifies makefile maintenance. This is the whole point of the
package. So far, converting GnuCash's Makefile.in to GnuCash's
Makefile.am has been straightforward.
The potential downsides:
- Another package for maintainers to install. But end users who just
want to compile the package don't need automake.
- Current versions have a dependency mechanism that requires that gcc
be used by the person updating dependencies. (it is otherwise
automatic)
- Forces a model where separate build directories are used to build
for different toolkits. No more make time differentiation. While
this is standard behavior for GNU packages, I don't want to rock any
boats.
- There are no automake smarts for guile installation. That'll have
to remain custom.
- I didn't do the original multi-target support for the current
gnucash. I may miss some subtleties.
I'd appreciate any thoughts people had on this. If nobody raises a
red flag, I'll continue to poke around with this. If in the end
automake still seems like a good fit, I'll send off a patch.
--
matt - http://www.lickey.com
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
