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

Re: automake fun



"Steve M. Robbins" <steven.robbins@videotron.ca> writes:

> True.  :-/

As much as I wish it wasn't...

> 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.

Right.  But even doing trivial fixes to Makefile.am just adds to the
time needed to fix bugs in the (I believe) rather large set of
packages which need to be fixed.

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

Agreed.

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

I do think this is probably the best long-term solution.

> 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?]

Well, if a package modifies Makefile.am in the Debian diff, it will
either have to:

1) add the corresponding patch to the Makefile.in in the Debian diff
2) Build-Depend on automake, and rerun automake as part of the build
   process (ugly ugly)

> 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.

Exactly, I just want a consistent solution so when (for example) I am
doing an NMU to fix other bugs in a package, I can fix this issue as
well if it hasn't been already.  And also maintainers can fix their
packages.

> 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.

I think so too.

> 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.

Right.  Well, I guess then we should recommend this solution in the
short term, and the AM_MAINTAINER_MODE in the long term.



Reply to: