autoconf
[Top][All Lists]
Advanced

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

Re: "has changed since the previous run"


From: Ralf Wildenhues
Subject: Re: "has changed since the previous run"
Date: Fri, 2 Feb 2007 18:31:03 +0100
User-agent: Mutt/1.5.13 (2007-01-26)

* DJ Delorie wrote on Fri, Feb 02, 2007 at 02:42:41PM CET:
> 
> > > IMHO autoconf's test shouldn't be so sensitive to whitespace
> > > changes.
> > 
> > You keep saying that, but that doesn't make it more right.
> 
> Since I'm merely stating my opinion, by definition it is right.

Certainly.  Sorry if my opinion came over as more than just that.

> Whether or not the test should change is, of course, debatable.

> But I fail to see the point of a test that fails (not just warns)
> about CFLAGS changing from "-O2" to "-O2 ".

Well, rewriting the test to be robust against whitespace changes would
have been more work than fixing AC_CONFIG_SUBDIRS to not munge
whitespace, and the latter needed to be done anyway, for things like
  .../configure --enable-foo='  bar  baz  '

to pass all whitespace down to the sub-configure script correctly.
And given that fix, there is no need for the other fix anymore AFAICS.

> > And they go away if I rebuild, with Autoconf-2.60, newlib/configure and
> > all other configure scripts that themselves call AC_CONFIG_SUBDIRS.
> 
> Hmmm... I'll have to try with 2.60 then.  I reviewed the changes
> therein but didn't see anything that would have solved the whitespace
> problem.

The relevant change is the one from 2006-05-06.  Related fixes for more
obscure issues not directly related to your bug report were applied on:
2006-11-17, 2006-09-13, 2006-05-26, 2006-05-18.

> > Should I hack up a patch that fixes things for you for 2.59 only?
> 
> Given the relatively large number of packages I'm dealing with, and
> how many people are re-autoconfing them, I don't think that would be a
> viable solution.
> 
> If 2.60 fixes it, I might petition to have everyone move to that.

Please postpone your petition and your judgement over the alternative
until you have seen it.  I should have a working patch soon which adds a
macro file to newlib which will allow you to continue to use stock 2.59.

Independently, I would anyway be interested in issues that keep you
(GCC, binutils, ...) from moving to 2.61 rather than 2.60 or 2.59.
Backporting fixes may be more work in the end than going forward.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]