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
macros.
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
debian/rules:
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.
Cheers,
-Steve
--
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: