On Tuesday, 18 July 2006 at 00:40, Matthias Andree wrote:
> Greetings,
>
> ever since I first checked out mutt from CVS, I was unhappy by the
> abominance of m4/Makefile.am.in and several other crude auto* code
> pieces. In order to improve maintainability a bit, I have taken the time
> to overhaul the build system, assuming that autotools experts are rare
> and their motivation is even lower. (Most hackers use GNU auto* but
> are loathe to touch the *.am/*.in/*.m4 files.)
Thanks, this kind of work has been sorely needed for a long time. Most
of the cruft has more to do with leftover workarounds for autoconf
2.13/automake 1.4 and the old crypto/non-crypto distribution hooks
than incompetence, by the way :)
I'd be grateful if Lars Hecking, the local auto* expert could give
this a once-over. Lars?
> These are the changes, fixing a bunch of bugs as I went, and installing
> Muttrc.dist and mime.types.dist additionally to ease uninstallation.
>
> As the changes are interdependent, I have not taken them out
> individually. Patch attached with text/x-patch MIME type.
>
> - install Muttrc and mime.types as *.dist, and on "make uninstall",
> remove the real files if identical to *.dist. For "make distcheck".
> Procedures like these are common practice on the *BSD systems.
ok, but this does sound like a candidate for separating out of your
large patch and submitting later.
> - m4/Makefile.am.in is not needed (a next step might switch prepare over
> to autoreconf once the po/Makefile.in.in hacks are gone).
> Replaced it by a real m4/Makefile.am to avoid special treatment.
great.
> - several obsolete variables in Makefile.am have been updated
> (INCLUDES -> AM_CPPFLAGS) to fix automake -Wall warnings.
> Automake 1.4 has been history for many years.
ok.
> - doc/Makefile.in and contrib/Makefile.in lacked several standard
> targets. Replaced these files by Makefile.am, moving manually coded
> (un)install and dist targets into variables or appropriate -local and
> -hook targets. This gives the user all standard targets and helps fix
> "make distcheck" to see if the distribution is self-contained.
> ("make distcheck" should become part of the build-release script)
these I'll have to review or get a second opinion on.
> Good side effect: ./configure && make dist now works without prior
> "make all" (is broken in current CVS).
>
> - list files to (dist)clean properly, needed for "make distcheck"
>
> - dropped bogus Makefile: $(BUILT_SOURCES) dependency (if you think this
> was needed, check with automake 1.9 and dependency tracking enabled,
> i. e. run: "automake && ./config.status" and see for yourself)
>
> - add two hacks to get "make distcheck" working (see TODO below):
> + make srcdir writable and trash keymap_alldefs.h when building it
> + dito in po/Makefile.in.in for mutt.pot
keymap_alldefs is a leftover from the crypto split IIRC. I don't think
it's needed any more.
>
> I think these additional CVS commands are needed *before* the commit:
>
> patch <tidy-buildsystem-20060717.patch
> cvs rm -f m4/Makefile.am.in doc/Makefile.in contrib/Makefile.in
> cvs add m4/Makefile.am doc/Makefile.am contrib/Makefile.am
>
> Be sure not to run "cvs update" or "make" between patching and the
> cvs rm, to avoid files reappearing.
>
>
> TODO in later revisions (I haven't listed these in TODO, let me know if
> you want an incremental patch to do that).
>
> - get rid of the ugly automake "-i" unless "./prepare -dev ..." is
> run. If somebody checks the code out from CVS, it can safely be
> assumed that dependency tracking and maintainer mode are desired.
this is good. I'd like autoreconf to just work - prepare itself is
somewhat old-fashioned nowadays.
> - get rid of the keymap_alldefs.h hack. Probably yet another dependency
> or distfiles bug I've not yet found.
>
> - get rid of po/Makefile.in.in hacks so that the original gettext
> Makefile.in.in works. Same suspicion.
>
> - include "make distcheck" and other safety nets into build-release.
>
>
> BTW, does anyone have a good workflow and/or tool suggestion for
> tracking cvs rm and cvs add for a read-only CVS repo?
I'd recommend using the hg or git CVS mirrors (I maintain a couple at
mutt.kublai.com). It's a lot easier to track your own development that
way.
Attachment:
pgp1ma96LKzkh.pgp
Description: PGP signature