Re: more build sherrif-ery (and a touch of auto*)

[Havoc Pennington <hp redhat com>]

On Fri, 2004-11-12 at 14:57 -0500, Daniel Reed wrote:
> ) There's no insistence on a particular version; the insistence is on a
> ) particular *interface contract* given a particular *name*
> 
> The best I can say is that the autotools are designed so that such a
> contract does should not be necessary.

That is the crux of the problem, I think.

The contract *is* necessary with the way we're using autotools, and by
using the automake-1.x binaries we effectively get this contract.

There are hundreds of developers and hundreds of modules using shared
CVS who need to run the autotools and change build control files; and
then distribution developers using tarballs typically need to change
build control files in some number of random modules, and re-run the
appropriate autotools for the modules they happen to change.

We could check all the generated files into CVS, but I think you'd find
unanimous opposition among module maintainers to doing that. Because it
has a lot of bad aspects.

I do understand that autotools are designed for that - I've had long
flamefests about it in the context of libtool, for example.

So I understand that the autotools maintainers aren't going to change
their mind, but at the same time this aspect of autotools fundamentally
does not work well for GNOME. That's why we asked for the automake-1.x
binary names, and we can use those (in combination with autogen.sh
scripts) to massage automake into a model that works OK for us. It's
much appreciated that the autotools developers provided this workaround
and I think in doing so they recognized that we aren't using the usual
model.

The only point I'm making in this thread is that we need to continue to
use that workaround. /usr/bin/automake is useful in the single-
maintainer-generates-the-generated-files universe, not in a universe of
dozens of versions of multiple distributions, hundreds of developers,
and hundreds of modules.

Porting to new automake quickly - good.
Warnings about the need to port - good.
Silently trying to use an automake a package hasn't ported to - bad.

What we may be able to do, if some of the automake releases are in fact
compatible, is group the compatible ones via autogen.sh. e.g. if a
package whitelists 1.7 it could automatically whitelist 1.8 also
(assuming those two are compatible, I have no idea if they are).
This would be a workaround for cases where automake should not have
changed the binary name since the interface was maintained.

I don't know if you are actually arguing for a "use the latest" symlink
in autogen.sh anymore or not, if you aren't then I'm not sure we
disagree in important ways.

Nobody disagrees that we should take patches to make modules use newer
automake, either, of course.

Havoc