Why autoconf 2.13?

Why autoconf 2.13?

[Fred Fish]

Is there some reason that gdb is using a 3 year old version of
autoconf instead of the latest official FSF release (2.53 I think)?

-Fred

Re: Why autoconf 2.13?

[Daniel Jacobowitz]

On Wed, Apr 10, 2002 at 05:39:12PM -0700, Fred Fish wrote:
> Is there some reason that gdb is using a 3 year old version of
> autoconf instead of the latest official FSF release (2.53 I think)?
> 
> -Fred

Because all the rest of sourceware is.  Every so often there are noises
made about moving forward, but 2.53 and 2.13 aren't even mostly
compatible in practice.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Why autoconf 2.13?

[Christopher Faylor]

On Wed, Apr 10, 2002 at 08:41:03PM -0400, Daniel Jacobowitz wrote:
>On Wed, Apr 10, 2002 at 05:39:12PM -0700, Fred Fish wrote:
>>Is there some reason that gdb is using a 3 year old version of autoconf
>>instead of the latest official FSF release (2.53 I think)?
>
>Because all the rest of sourceware is.  Every so often there are noises
>made about moving forward, but 2.53 and 2.13 aren't even mostly
>compatible in practice.

Alexandre Oliva was showing some interest in upgrading everything but
we've been keeping him too busy with "real work" for this to become
a reality.

I think he probably has a pretty good handle on what needs to be done,
though.  I don't want to volunteer him for anything but maybe he'd be
interested in coordinating an upgrade effort for gcc.gnu.org and
sourceware.

cgf

Re: Why autoconf 2.13?

[DJ Delorie]

Fred Fish <fnf@fred.ninemoons.com> writes:
> Is there some reason that gdb is using a 3 year old version of
> autoconf instead of the latest official FSF release (2.53 I think)?

There are problems with autoconf 2.5x reading a config.cache from
2.13.  I haven't heard any word about that being fixed.  Plus, it's a
good idea to support the most recent 2 major releases, and 2.13 is
still in that category.  It's also the autoconf that's preinstalled on
Red Hat Linux 7.2.

We don't automatically start using newer support tools just because
they've been released.  We need a compelling reason to force all the
users to upgrade their machines, and we haven't seen one yet.

Re: Why autoconf 2.13?

[Tom Tromey]

>>>>> "DJ" == DJ Delorie <dj@redhat.com> writes:

DJ> We don't automatically start using newer support tools just
DJ> because they've been released.  We need a compelling reason to
DJ> force all the users to upgrade their machines, and we haven't seen
DJ> one yet.

Doing it will let us use a newer automake, which in turn will let us
remove a bunch of hacks from various Makefile.am's.  Also it will mean
that libgcj won't need to continue using its own hacked automake.  The
big problem is just that nobody with the expertise has the time (or
maybe interest :-).

Tom

Re: Why autoconf 2.13?

[DJ Delorie]

Tom Tromey <tromey@redhat.com> writes:
> Doing it will let us use a newer automake, which in turn will let us
> remove a bunch of hacks from various Makefile.am's.  Also it will mean
> that libgcj won't need to continue using its own hacked automake.  The
> big problem is just that nobody with the expertise has the time (or
> maybe interest :-).

Have they fixed the problem with old config.caches in 2.5 yet?

Re: Why autoconf 2.13?

[Andreas Schwab]

DJ Delorie <dj@redhat.com> writes:

|> Tom Tromey <tromey@redhat.com> writes:
|> > Doing it will let us use a newer automake, which in turn will let us
|> > remove a bunch of hacks from various Makefile.am's.  Also it will mean
|> > that libgcj won't need to continue using its own hacked automake.  The
|> > big problem is just that nobody with the expertise has the time (or
|> > maybe interest :-).
|> 
|> Have they fixed the problem with old config.caches in 2.5 yet?

What's wrong with "rm config.cache"?  autoconf 2.50+ does not even create
a config.cache by default any more.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why autoconf 2.13?

[DJ Delorie]

> What's wrong with "rm config.cache"?  autoconf 2.50+ does not even create
> a config.cache by default any more.

The problem is when someone does "cvs update" and suddenly everything
breaks because they got a newly configured configure which doesn't
like the config.cache they've got sitting around.

Re: Why autoconf 2.13?

[Andreas Schwab]

DJ Delorie <dj@redhat.com> writes:

|> > What's wrong with "rm config.cache"?  autoconf 2.50+ does not even create
|> > a config.cache by default any more.
|> 
|> The problem is when someone does "cvs update" and suddenly everything
|> breaks because they got a newly configured configure which doesn't
|> like the config.cache they've got sitting around.

I still regard it as an acceptable workaround, since the data in it can
become stale quite easily anyway, just by changing anything in the build
environment.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Why autoconf 2.13?

[Andrew Cagney]

> DJ Delorie <dj@redhat.com> writes:
> 
> |> > What's wrong with "rm config.cache"?  autoconf 2.50+ does not even create
> |> > a config.cache by default any more.
> |> |> The problem is when someone does "cvs update" and suddenly everything
> |> breaks because they got a newly configured configure which doesn't
> |> like the config.cache they've got sitting around.
> 
> I still regard it as an acceptable workaround, since the data in it can
> become stale quite easily anyway, just by changing anything in the build
> environment.

Yes.  If an update contains autoconf changes, I always end up rebuilding 
from scratch.

Andrew