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

Previous Next

Package: automake;

Reported by: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Date: Thu, 30 Dec 2010 22:33:02 UTC

Severity: normal

Tags: confirmed, help

Full log


View this message in rfc822 format

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7763 <at> debbugs.gnu.org
Subject: 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




This bug report was last modified 4 years and 208 days ago.

Previous Next


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