Planning for the Autoconf 2.5x transition?
Mon Dec 23 21:57:00 GMT 2002
OK, this subject has come up before, but I think it's time to bring it
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
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
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...
More information about the Newlib