This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Planning for the Autoconf 2.5x transition?
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: gcc at gcc dot gnu dot org
- Cc: gdb at sources dot redhat dot com, binutils at sources dot redhat dot com, newlib at sources dot redhat dot com
- Date: Tue, 24 Dec 2002 00:56:06 -0500
- Subject: Planning for the Autoconf 2.5x transition?
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