[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: automake fun

On Tue, Nov 20, 2001 at 10:48:04PM -0500, Colin Walters wrote:
> "Steve M. Robbins" <steven.robbins@videotron.ca> writes:
> > Well, normally that is not a problem either: if configure detects
> > automake, and runs it, that usually works.  If not, there is a bug
> > in the package's auto-* input files (configure.in, Makefile.am,
> > etc).
> Upstream maintainers tend to have a lot of broken stuff in their
> Makefile.am. 

True.  :-/

Although I find that stuff in Makefile.am proper is usually trivially
fixable; perhaps you've been unluckier than I.  In my experience the
really bad stuff happens when people start rolling their own autoconf

Not that it matters much; it is a problem to deal with either way.

> > If the package files are buggy and don't work with, say automake1.5,
> > then using build-conflicts seems the cleanest option, to me.  Or fix
> > the package.
> Well, I personally dislike the Build-Conflicts solution, as it would
> require updating all packages if a new automake package (say,
> automake1.6) or something hit the archive.  It just seems to
> heavyweight for this.

Yes, I see your point.  In that light, the AM_MAINTAINER_MODE
solution of Matt Z sounds more attractive.

> But the reason I asked here is to get other opinions.  I think having
> a consistent solution to problems like this is important.  If most
> people agree that Build-Conflicts is the way to go, then we should
> document this in /usr/share/doc/autotools-dev/README.Debian.gz, and
> more maintainers will hopefully start using it.

Something is not clear to me: are you advocating that *every* package
that contains Makefile.am needs to do something?  [Or every package
that modifies its Makefile.am?]

It isn't clear to me that the problem is widespread enough to mandate
that every package care about the version of autoconf & friends.

Or are you advocating a consistent solution for packages that have 
been shown to have a problem: e.g. a package that failed to build
on one of Debian's autobuilders?

For such packages, I agree that documenting a good solution for folks
to use is desirable.  

Solutions that involve manually commenting-out parts of the generated
Makefile.ins or touching files in the right order seem way too fragile
to me.  I worry that internal changes to autoconf/automake/libtool/etc
would upset the whole system.  Better to work within the automake
framework, I'd say.

In that light, the AM_MAINTAINER_MODE solution seems attractive.  But
if you don't like changes to upstream source, then one can get the
same effect by setting some variables when invoking make in

    make ACLOCAL="`pwd`/missing aclocal" \
	AUTOCONF="`pwd`/missing autoconf" \
	AUTOMAKE="`pwd`/missing automake" \
	AUTOHEADER="`pwd`/missing autoheader"

Of course, I got that list from peeking at a generated Makefile, so it
is most likely incomplete; you'll probably want something for
e.g. libtool, if applicable.  I'd say that this solution is less
robust than AM_MAINTAINER_MODE, but can be done in debian/rules only,
so is better for NMUs ?  

Actually, I expect that you can get away with setting AUTOCONF and
AUTOMAKE only, in many cases.


by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Reply to: