Re: Use of automake & friends vs. just running configure
Scott James Remnant <scott@netsplit.com> writes:
> On Tue, 2004-09-07 at 21:09 +0200, Francesco Paolo Lovergine wrote:
>
>> On Tue, Sep 07, 2004 at 07:36:07PM +0100, Scott James Remnant wrote:
>> > On Tue, 2004-09-07 at 16:31 +0200, Francesco P. Lovergine wrote:
>> >
>> > > Convincing upstreams to use AM_MAINTAINER_MODE macro with automake helps.
>> > >
>> > That would be wrong.
>> >
>> End users do not change Makefile.am or any other file like that, because
>> they are indeed end users, not developers.
> *snip*
>> Any developer with a minimum of brain in its head knows
>> --enable-maintainer-mode and knows how to change properly things in
>> autotools scripts.
>>
> So when a user does, for whatever reason, end up changing Makefile.am
> (they might be applying a patch, or just muddling about) they *don't*
> have this developer knowledge so wouldn't get a dependable build.
>
> That's why it's a bad default, it optimises for intelligence rather than
> stupidity and there's rather more of the latter in the world :-(
>
> To quote from the Automake documentation:
>
> Several years ago François Pinard pointed out several arguments
> against `AM_MAINTAINER_MODE'. Most of them relate to
> insecurity. By removing dependencies you get non-dependable
> builds: change to sources files can have no effect on generated
> files and this can be very confusing when unnoticed. He adds
> that security shouldn't be reserved to maintainers (what `--
> enable-maintainer-mode' suggests), on the contrary. If one user
> has to modify a `Makefile.am', then either `Makefile.in' should
> be updated or a warning should be output (this is what Automake
> uses `missing' for) but the last thing you want is that nothing
> happens and the user doesn't notice it (this is what happens
> when rebuild rules are disabled by `AM_MAINTAINER_MODE').
>
> There is a good suggestion that AM_MAINTAINER_MODE should be built-in,
> but with the defaults *reversed*, so that those developers with brains
> in their heads can --disable-maintainer-mode if they want.
Why not make a middle mode where the depends are added but generate an
error explaining the inconsistency.
That way inexperienced users would get a helpfull message, builds
would be dependable and updating automake would not cause
incompatibilities all over the place.
The best of both worlds.
>> Instead they are confused and upset by cryptical errors of autotools,
>> when new versions are not backcompatible as often (if not always)
>>
> Which recent (let's say the last 5 years) versions haven't been
> backwards compatible? If you've got an example, I'd like to see it so
> we can get a test case and fix that bug.
Oehm, how about all of them?
Examples? Tons of them. Read the BTS. The last one I reported is
gnutls10 in sarge.
Need more examples?
mrvn@dual:~% grep-dctrl -F Build-Depends automake /var/lib/apt/lists/*Source* -s Build-Depends | grep automake1.6 | wc
131 2081 22924
mrvn@dual:~% grep-dctrl -F Build-Depends automake /var/lib/apt/lists/*Source* -s Build-Depends | grep automake1.7 | wc
455 7458 76773
mrvn@dual:~% grep-dctrl -F Build-Depends automake /var/lib/apt/lists/*Source* -s Build-Depends | grep automake1.7 | grep automake1.6 | wc
33 682 8008
Repeat for any other combination of versions.
> Scott
> --
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
MfG
Goswin
Reply to: