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.
Description: PGP signature