This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Planning for the Autoconf 2.5x transition?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]