qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Meyering <...@meyering.net>
Subject Re: Automake build system up and running :)
Date Mon, 04 Dec 2006 20:48:05 GMT
Alan Conway <aconway@redhat.com> wrote:

> On Mon, 2006-12-04 at 15:33 +0000, Steven Shaw wrote:
>> On 04/12/06, Jim Meyering <jim@meyering.net> wrote:
>> > I think you said Debian.  If so, you can safely use apt preferences
>> > (see man apt_preferences) to get automake, autoconf, and libtool from
>> > "unstable", which btw, doesn't deserve that name any more.
>> Does that mean that it will work now with autoconf >2.59 ?
> It was originally working with 2.60, I downgraded to 2.59 because that's
> the latest on fedora 6. I've no objection to downgrading further, e.g.
> for RHEL 4. I don't know why you would be having trouble with a higher
> version though.
>> Perhaps you could post the ./configure script. That's all I need. Or
>> perhaps commit it to svn under a sneaky name like "configure.sneaky".
> What do you think Jim? My instinct is to never commit generated files,

That's my preference, too.
There are problems no matter which approach you take.
In the four months since I switched GNU coreutils development
to the ./bootstrap-style approach, I get the impression that
it makes the development code base more accessible to potential
participants.  Before, derived files like configure, aclocal.m4,
and Makefile.in were all version-controlled, but it was too easy
to change configure.ac or a Makefile.am file and then forget to
regenerate-and-commit the associated generated files.  That would
render a checked-out-copy unbuildable by average users.  In addition,
there would sometimes be conflicts in those generated files due to
developers using differing versions of tools like automake and autoconf.

> but if this is likely to get in the way of contributors then perhaps we
> should consider it.

I've found that it's better to try to educate developers than
to try to accommodate inadequate build environments.
Maybe we need more detailed instructions on how to set up a proper
build environment from scratch?  Or a FAQ, on things that can go wrong?

Also, for *developers*, there is little point in providing too much
backwards compatibility wrt tools like automake and autoconf.
There is no harm in requiring that they upgrade to the latest tools.
And there *is* harm in our spending time (and more importantly making
the infrastructure less modern) to backport developer-only infrastructure.


View raw message