Re: [PATCH] Build system cleanup, take #1
Brendan Cully <brendan@xxxxxxxxxx> writes:
> 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 didn't claim it was incompetence. It's just the usual bit-rot in
projects that have been around for long, and my experience is that
hackers rather work on the C code than the build environment.
If the important contributors and maintainers can cope with what we've
got after the fixing session, that's about as far as I'm willing to go
backwards. Don't beg me for autoconf 2.52 or automake 1.5 compatibility,
I won't care unless paid. :)
>> - 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.
Still a "make distcheck" requirement (which demands that make uninstall
mustn't leave anything behind that make install threw on your disk), but
it's self-contained and thus easy to leave out. OTOH it doesn't change
existing behavior except that it's easier to detect changes at uninstall
time.
>> - 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.
Well, I did "make dist" before and after the patch and the difference in
packaged files were m4/Makefile.am.in gone and contrib/Makefile.am and
dist/Makefile.am newly added, if that calms your concerns.
>> - 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 couldn't judge that in the timeframe I took for fixing up the auto*
stuff.
>> 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.
Mercurial or Cogito sound good. What do you recommend?
I'm only superficially familiar with either of them. I've occasionally
checked out stuff with cg and hacked a few bits into hg (e2fsprogs).
--
Matthias Andree