GNU bug report logs - #7763
Remake rules botch up when 'foreign' and 'ignore-deps' are removed from AM_INIT_AUTOMAKE

Previous Next

To reply to this bug, email your comments to 7763 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Remake rules botch up when 'foreign' and 'ignore-deps' are removed
	from AM_INIT_AUTOMAKE
Date: Thu, 30 Dec 2010 23:38:45 +0100

[Message part 1 (text/plain, inline)]

Hello automakers.

Currently, the Automake-generated rebuild rules[1] invoke automake with
some command-line options derived from arguments given to AM_INIT_AUTOMAKE.

[1] For more info, see:
    <http://www.gnu.org/software/automake/manual/html_node/Rebuilding.html>

For example, putting `foreign' in AM_INIT_AUTOMAKE generates remake rules
that rebuild outdated Makefile.in files using "$(AUTOMAKE) --foreign";
similarly, `no-dependencies' in AM_INIT_AUTOMAKE generates remake rules
that rebuild outdated Makefile.in files using "$(AUTOMAKE) --ignore-deps".

This semantic clearly breaka remake rules in the (admittedly unlikely and
corner-case) situation when e.g., `foreign' or `no-dependencies' arguments
are removed from the call to AM_INIT_AUTOMAKE (see attached testcases,
which should work with latest master -- v1.11-564-g635a250).

Let's now see explicitly and in detail how this happens (for the case of
the `foreign' option) ...

-*-*-

First, the developer creates a configure.ac that contains:
  AM_INIT_AUTOMAKE([foreign -Wall])
He runs aclocal, autoconf and automake; this generates a Makefile.in that
contains rebuild rules which call automake as "$(AUTOMAKE) --foreign".
He then runs configure, and those rebuild rules end up verbatim in the
generated Makefile.

At this point, the developer decides he wants to switch to the 'gnu'
strictness for his package; since 'gnu' is indeed the default strictness,
he simply modifies the AM_INIT_AUTOMAKE call to read:
  AM_INIT_AUTOMAKE([-Wall])
and then run "make", trusting that the rebuild rules in Makefile will
do all the required updates for him.

But alas, the existing rebuild rules in the Makefile will call
"$(AUTOMAKE) --foreign", and so, since no strictness is explicitly
specified in AM_INIT_AUTOMAKE, the 'foreign' strictness will still
be used.

-*-*-

Cooking up a patch to fix this problem shouldn't be difficult; but such a
patch would need to touch the same parts of the code modified by the pending
patch series "Explicit warning levels must always take precedence over those
implied by the strictness":
 <http://lists.gnu.org/archive/html/automake-patches/2010-12/msg00139.html>
Thus I will wait for that series to be applied first, to spare me useless
conflicts when merging and/or rebasing.

Regards,
   Stefano

[remake-after-removing-foreign-option.test (application/x-shellscript, inline)]

[remake-after-removing-nodeps-option.test (application/x-shellscript, inline)]

Message #8 received at 7763 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7763 <at> debbugs.gnu.org
Subject: Re: bug#7763: Remake rules botch up when 'foreign' and 'ignore-deps'
	are removed from AM_INIT_AUTOMAKE
Date: Sun, 2 Jan 2011 06:50:13 +0100

Hello Stefano,

* Stefano Lattarini wrote on Thu, Dec 30, 2010 at 11:38:45PM CET:
> Currently, the Automake-generated rebuild rules[1] invoke automake with
> some command-line options derived from arguments given to AM_INIT_AUTOMAKE.
> 
> [1] For more info, see:
>     <http://www.gnu.org/software/automake/manual/html_node/Rebuilding.html>
> 
> For example, putting `foreign' in AM_INIT_AUTOMAKE generates remake rules
> that rebuild outdated Makefile.in files using "$(AUTOMAKE) --foreign";
> similarly, `no-dependencies' in AM_INIT_AUTOMAKE generates remake rules
> that rebuild outdated Makefile.in files using "$(AUTOMAKE) --ignore-deps".

I agree that this is a bug.

Question is, does removing the arguments break other, legitimate uses?
Or was this functionality purely added at a time before automake could
trace configure.ac macros?

The tests might suffer from the trace caching bug as well, haven't
checked.

Thanks,
Ralf

Message #11 received at 7763 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 7763 <at> debbugs.gnu.org
Subject: Re: bug#7763: Remake rules botch up when 'foreign' and 'ignore-deps'
	are removed from AM_INIT_AUTOMAKE
Date: Sun, 2 Jan 2011 12:00:56 +0100

On Sunday 02 January 2011, Ralf Wildenhues wrote:
> Hello Stefano,
> 
> * Stefano Lattarini wrote on Thu, Dec 30, 2010 at 11:38:45PM CET:
> > Currently, the Automake-generated rebuild rules[1] invoke automake with
> > some command-line options derived from arguments given to AM_INIT_AUTOMAKE.
> > 
> > [1] For more info, see:
> >     <http://www.gnu.org/software/automake/manual/html_node/Rebuilding.html>
> > 
> > For example, putting `foreign' in AM_INIT_AUTOMAKE generates remake rules
> > that rebuild outdated Makefile.in files using "$(AUTOMAKE) --foreign";
> > similarly, `no-dependencies' in AM_INIT_AUTOMAKE generates remake rules
> > that rebuild outdated Makefile.in files using "$(AUTOMAKE) --ignore-deps".
> 
> I agree that this is a bug.
> 
> Question is, does removing the arguments break other, legitimate uses?
> Or was this functionality purely added at a time before automake could
> trace configure.ac macros?
>
Well, the use of `--foreign' etc. in automake calls in rebuild rules
was already in place at least in commit `Release-1-0-5-g415b068' of
10/06/1996 (back then, the option really used was the now-obsolete
`--strictness=STRICTNESS-LEVEL').

Also, the use of `--ignore-deps' in automake calls in rebuild rules
was added with commit `Release-1-1p-11-g27ccbf2' of 27/05/1997.

At the time those commits were done, no tracing of autoconf macros nor
setting of automake options in AM_INIT_AUTOMAKE were available, and so
the only way to enable a particular strictness and/or the option
`no-dependencies' globally was to pass proper command line arguments
to automake.

> The tests might suffer from the trace caching bug as well, haven't
> checked.
>
Am I missing something, or is this a quite serious bug of autom4te?

Thanks,
   Stefano

Message #14 received at 7763 <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7763 <at> debbugs.gnu.org
Subject: Re: bug#7763: Remake rules botch up when 'foreign' and 'ignore-deps'
	are removed from AM_INIT_AUTOMAKE
Date: Sun, 2 Jan 2011 12:18:56 +0100

* Stefano Lattarini wrote on Sun, Jan 02, 2011 at 12:00:56PM CET:
> On Sunday 02 January 2011, Ralf Wildenhues wrote:
> > Question is, does removing the arguments break other, legitimate uses?
> > Or was this functionality purely added at a time before automake could
> > trace configure.ac macros?
> >
> Well, the use of `--foreign' etc. in automake calls in rebuild rules
> was already in place at least in commit `Release-1-0-5-g415b068' of
> 10/06/1996 (back then, the option really used was the now-obsolete
> `--strictness=STRICTNESS-LEVEL').
> 
> Also, the use of `--ignore-deps' in automake calls in rebuild rules
> was added with commit `Release-1-1p-11-g27ccbf2' of 27/05/1997.
> 
> At the time those commits were done, no tracing of autoconf macros nor
> setting of automake options in AM_INIT_AUTOMAKE were available, and so
> the only way to enable a particular strictness and/or the option
> `no-dependencies' globally was to pass proper command line arguments
> to automake.

Thanks for the research.  It seems we should move away from this then.
Only thing I really wonder is why Alexandre (or Akim) didn't do that at
the time autoconf tracing started to be used.  It seems like such an
obvious move to make that it makes me unsure we're overlooking
something.

> > The tests might suffer from the trace caching bug as well, haven't
> > checked.
> >
> Am I missing something, or is this a quite serious bug of autom4te?

Well, it seems to work fine when we ensure configure.ac is strictly
newer than the files in autom4te.cache.  But I wanted to avoid sleeping.
So I tried --force, but that failed.  The two things I still need to
check are: do 'aclocal --force' and 'automake --force' need to pass
--force to 'autom4te --trace' resp. 'autoconf --trace' and do things
work out then?

Cheers,
Ralf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.