Planning for the Autoconf 2.5x transition?

[Nathanael Nerode <neroden@twcny.rr.com>]

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