Planning for the Autoconf 2.5x transition?

Planning for the Autoconf 2.5x transition?

[Nathanael Nerode]

OK, this subject has come up before, but I think it's time to bring it 
up again.

Autoconf 2.5x would be a significant improvement to the configure 
machinery.  It's not an entirely compatible transition.  But we have to 
do it, and I'd prefer sooner rather than later.

There are several questions to be resolved here.

I see three primary schemes which could be used for this:
1. Make all directories have configure.in scripts which work correctly 
with *both* 2.13 and 2.5x, then switch over.

The major problem with this is that I think it's probably impossible.  
At least some directories will need to have different code for the two 
versions.

2. Transition one subdirectory at a time.

The major problem with this is that for quite a while, two versions of 
autoconf would be needed to rebuild the whole tree.

3.  Create autoconf-2.5x branches in src and gcc.

The major problems with this are the need to port any configury changes 
up from the trunk, the general nasty slowness of CVS branches, and the 
future difficulty of getting the branch merge approved by all projects 
at once.

--
I'm happy to attempt to coordinate whichever scheme is considered best.
I just think that this should actually be started, so that it will be 
finished sometime in the next three months or so.

The next question is: what are the actual, known problems with changing to 
autoconf 2.5x?  The libstdc++-v3 maintainers have noted the particular 
problems they have; I haven't heard comments about particular problems 
with any other subdirectories.

--
The reason I'm harping on this is that a number of my other little 
configury projects would be a lot happier with an autoconf which 
provided m4_include.  Large change for that one benefit, I know...

--Nathanael

Re: Planning for the Autoconf 2.5x transition?

[Alexandre Oliva]

On Dec 24, 2002, Nathanael Nerode <neroden@twcny.rr.com> wrote:

> 1. Make all directories have configure.in scripts which work correctly 
> with *both* 2.13 and 2.5x, then switch over.

This was my plan, back when I thought I'd ever have time to put into
this effort.

> The major problem with this is that I think it's probably impossible.  
> At least some directories will need to have different code for the two 
> versions.

You can write m4 conditionals on the autoconf version and have code
for 2.13 and for 2.5x, where it is actually needed.  In most cases,
all you should need is to fix m4 quoting errors that autoconf 2.13
didn't care about but that autoconf 2.5x happens to trip over.

> 2. Transition one subdirectory at a time.

> The major problem with this is that for quite a while, two versions of 
> autoconf would be needed to rebuild the whole tree.

This is possible, but it takes some additional effort because of
caching issues.  The one that comes to mind is that some early 2.5x
versions of autoconf changed the cache value of AC_EXEEXT in the
no-extension case in a way that autoconf 2.13 would think the
extension was .no.  If any sub-package happens to use a configure
script generated by such versions of autoconf, any subsequent
configure runs of scripts generated by autoconf 2.13 would be in
trouble.  I'm not sure this was actually `fixed' in newer versions of
autoconf 2.5x.

> 3.  Create autoconf-2.5x branches in src and gcc.

I don't think this is a good idea.  It's unlikely we'll ever get
testing coverage for these changes before the branches are merged into
mainline.  The only advantage of a branch is that one could then take
his/her (your? :-) time to implement any needed changes and, by then,
some of them might have become obsolete.  Using conditional code in
configure scripts that actually require changes that are not bug-fixes
for latent bugs seems far superior to me.

> The next question is: what are the actual, known problems with changing to 
> autoconf 2.5x?

Quoting problems were the most common problem found by early adopters
of autoconf 2.5x.  The good news is that, when I first started playing
with the idea of converting the uberbaum tree to autoconf 2.5x, there
weren't any.

The second most common problem for multi-configure packages is (was?)
the AC_EXEEXT issue.  The fix is as simple and mechanical as
overriding the cache value such that it is autoconf-2.13 compatible
(empty) whenever it is found to be `no' just before updating the cache
file.  We could even override the AC_EXEEXT macro to that effect.

AC_NO_EXECUTABLES as of the latest version of autoconf is
unfortunately useless for gcc's target libraries.  I don't know
whether anything came out of the last time this was discussed in the
autoconf CVS tree.  It's easy enough to override it with our own
version, using m4 conditionals.  We can even use a back-port of the
feature for autoconf 2.13.

The one other issue that got me more worried as that a number of
configure.in scripts that (implicitly) ran a pair of AC_ macros that
both wanted to be the first to do compile (or preprocessor?) tests,
and they'd complain loudly at configure-generation (autoconf) time and
abort if they found that other tests had already been processed (even
the tests performed by the other such macro).  If there are two macros
like that, there's no ordering that could satisfy both, so this is a
bit of a problem.  I remember one of the macros was AC_ISC_POSIX, but
I don't remember the other.  I've no idea whether the problem is still
present in the current version of autoconf; you should know as soon as
you run into the problem.  IIRC, this problem affects packages that
use CY_GNU_GETTEXT, that AC_REQUIREs AC_ISC_POSIX.

> The reason I'm harping on this is that a number of my other little 
> configury projects would be a lot happier with an autoconf which 
> provided m4_include.  Large change for that one benefit, I know...

m4_include is just a different way to spell m4's include/sinclude, so
that's not a good reason to switch to autoconf 2.5x.  Have a look at
bfd/acinclude.m4 for sample uses of sinclude.  Heck, even
gcc/aclocal.m4 uses this trick these days :-)  And I see gcc/aclocal.m4
contains an AC_ISC_POSIX that works around the problem I mentioned
above.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Planning for the Autoconf 2.5x transition?

[Phil Edwards]

On Wed, Dec 25, 2002 at 12:47:04AM -0200, Alexandre Oliva wrote:
> This is possible, but it takes some additional effort because of
> caching issues.  The one that comes to mind is that some early 2.5x
> versions of autoconf
[...]
> I'm not sure this was actually `fixed' in newer versions of
> autoconf 2.5x.

If we're going to jump to something more recent than 2.13, we may as well
require a /fixed/ recent version.

Put another way, I'm assuming and suggesting that when we talk about "2.5x
and later" we're doing so only because we haven't decided what x will be.
/Not/ because we're going to try and support all versions of x>=0.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Planning for the Autoconf 2.5x transition?

[Nick Clifton]

Hi Nathanael,

> 1. Make all directories have configure.in scripts which work
> correctly with *both* 2.13 and 2.5x, then switch over.

I would prefer this scheme.


Cheers
        Nick

Re: Planning for the Autoconf 2.5x transition?

[Benjamin Kosnik]

> > 1. Make all directories have configure.in scripts which work
> > correctly with *both* 2.13 and 2.5x, then switch over.

>I would prefer this scheme.

I think this way lies continued stalemate. I don't see how both can be
made to work, and, if this cannot be accomplished (we have attempted
this for libstdc++), I'd rather have things work sanely with autoconf
2.5.x. It is an incredible inconvenience for me to not be able to use
the default autotools on RH 8 for libstdc++ work: because of this, I'm
motivated to get this working for libstdc++ as soon as possible.

I think a much saner approach is to take the target subdirs on a case by
case basis. 

Are all the target libs able to auto-gen configure/Makefiles with the
exact same autoconf/automake at the moment? That would surprise me. 

-benjamin