Re: "has changed since the previous run"

DJ Delorie <[EMAIL PROTECTED]> writes: > They share config.cache, because it saves a lot of time. Not any more. Nowadays every configured subdirectory gets its own cache. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, German

Re: "has changed since the previous run"

Quoting Andreas Schwab <[EMAIL PROTECTED]>: DJ Delorie <[EMAIL PROTECTED]> writes: They share config.cache, because it saves a lot of time. Not any more. Nowadays every configured subdirectory gets its own cache. This question is a bit off topic but I'd be interested in knowing why you cha

any reason not to enforce the build requirement: m4 >= 1.4.4 ?

I spent some time recently tracking down a bug that arose from an autoconf installation built using m4-1.4.2. My testing showed that autoconf built using any version of m4 older than 1.4.4 would have the same problem. I'm sure it would save others from spending the time to track down this sort of

Re: "has changed since the previous run"

> Not any more. Nowadays every configured subdirectory gets its own cache. Hmmm... I thought our source tree was up to date. I wonder if that would "solve" our problem. Still having autoconf be sensitive to trailing spaces seems overly paranoid. __

Re: "has changed since the previous run"

Hello Benoit, * Benoit Sigoure wrote on Thu, Feb 01, 2007 at 05:04:48PM CET: > Quoting Andreas Schwab <[EMAIL PROTECTED]>: > >DJ Delorie <[EMAIL PROTECTED]> writes: > >>They share config.cache, because it saves a lot of time. > > > >Not any more. Nowadays every configured subdirectory gets its ow

Re: "has changed since the previous run"

* DJ Delorie wrote on Thu, Feb 01, 2007 at 03:25:36AM CET: > > > Do you think that is feasible for GCC? I know it far too little to > > be able to judge. > > No, sorry. In gcc, binutils, gdb, newlib, et al; there is a toplevel > configure and Makefile. Configure programatically determines whic

Re: "has changed since the previous run"

> Would you please point me to one bug report where the issue actually was > only changed whitespace in the precious variables, or, even better, show > me how to reproduce the issue you observe (with a combined, up to date > tree)? http://sourceware.org/ml/newlib/2006/msg01038.html http://sourcew

Re: any reason not to enforce the build requirement: m4 >= 1.4.4 ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/1/2007 9:37 AM: > I spent some time recently tracking down a bug that arose from an autoconf > installation built using m4-1.4.2. My testing showed that autoconf built > using any version of m4 older than 1.4.4 would hav

Re: any reason not to enforce the build requirement: m4 >= 1.4.4 ?

Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 2/1/2007 9:37 AM: >> I spent some time recently tracking down a bug that arose from an autoconf >> installation built using m4-1.4.2. My testing showed that autoconf built >> using any version of m4 older than 1.4.4 would have th

Re: "has changed since the previous run"

> So, I am suspecting the "CFLAGS" leak in GCC's toplevel Makefile.in > triggering the ".. change since previous run", might have been fixed in > GCC since then. If gcc moved to separate caches between those, that might be hiding the bug, too. ___ Aut

Re: "has changed since the previous run"

> I am observing the "CFLAGS" issue in newlib-1.15.0 with gcc < 4.2, but I > am not observing this issue with gcc >= 4.2. > > So, I am suspecting the "CFLAGS" leak in GCC's toplevel Makefile.in > triggering the ".. change since previous run", might have been fixed in > GCC since then. Our tree i

Re: "has changed since the previous run"

> To work around this issue with gcc-4.1.x (I do not use it for gcc-4.0.x > nor gcc-4.2), I am using this hack below. We have that hack, plus a few others. I originally asked about this because I'd rather not have to keep hacking onto otherwise normal looking code just to avoid whitespace change