Hello,
if I rewrite the build system of Cyrus imap 2.4(.10) to use Automake to
generate the Makefile.in-files, will the patch be accepted in reasonable
time in git/master?
The advantages of using Automake:
* there is no more need to deal with problems concerning parallel builds
* preferences in /etc/config.site will be honoured
* with a Makefile.am it is very easy to make cyrus imap use shared
libraries with libtool (see bug 3095, and email from 24.06.2011 on
cyrus-devel: currently static binaries are huge). [At least from my
perspective adding libtool support afterwards is easy]
* Makefile.am files are easier to maintain than Makefile.in files
(from my perspective)
* make install, make dist, make distclean will just work (correctly)
* the output of 'make' can be made to look nicer (with silent-rules)
Possible problems:
* I am not sure right now, how can 'make install' be tweaked to
install files in /usr/cyrus/bin, but I guess this can be tweaked in the
worst case by moving the files from /usr/bin to /usr/cyrus/bin
* automake 1.11's lex.am file has to be patched in order to
acknowledge, that lex can output files other than lex.c and lex.
However this tweak is only necessary, when rebuilding Makefile.in from
Makefile.am (=not done by end users).
I like to have one Makefile.am per project, as described in the article
"Recursive Make Considered Harmful" by Peter Miller
(http://aegis.sourceforge.net/auug97.pdf). If it is for some reason not
possible to have at the end a single Makefile.am for cyrus imap, then at
least I would like to reduce the number of automake files as much as
possible. (With a single Makefile, when you change a file in
cyrus-imap/lib and recompile, you are forced to recompile not only
libimap.a, but all binaries, that depend on this library; the output
looks nicer with "silent-rules" as it is not printed, that the directory
is changed; and having a single Makefile speeds up the loading and
proceeding it, compared to loading several Makefiles)
Any comments?
Със здраве
Дилян
