Re: Partial autoconf transition thoughts

[Alexandre Oliva <aoliva@redhat.com>]

On Jun  9, 2003, Daniel Jacobowitz <drow@mvista.com> wrote:

> 4.  Specify the same thing for both
> 	2.13: Both will be overridden; test $CC for cross mode.
> 	2.57: Both will be overridden, will build natively.

Except that building natively is deprecated, and autoconf people have
already pushed for removing this alternative.  We probably don't want
to rely on it, unless the entire transition is going to be *very*
short, and I don't think it can possibly be, since we're not going to
have simultaneous releases of all of gcc, binutils, gdb and newlib,
such that one could take all of them after the conversion and build a
unified tree.

> So I guess I don't see what the problem is with doing one directory at a
> time.

There are also libtool issues.  We want to use a single libtool.m4,
and you say our current libtool.m4 doesn't work with autoconf 2.5x
(did I misunderstand?), and this was a problem I didn't know about
before.

> There are existence proofs that this (mostly!) works -
> readline has been using autoconf 2.57 since its last import.

I've heard people complain it was being configured as if for cross
compilation even on native builds.

> Could someone who thinks this won't work please speak up, before I
> waste a lot of time?

It should mostly work, but I still think we should pass different
arguments to sub-configures depending on which version of autoconf was
used to configure them.

> I tested a native build on i386-linux

What configure arguments?  Did you pass i386-linux in the command
line?  Maybe one of --build or --host?  The worst case to handle IMO
is that of passing --build, since then autoconf 2.13 directories will
guess --host from config.guess, whereas autoconf 2.57 will default
host to build.  If they're different, we get an inconsistent build
across directories.  That's why I think we should resolve the flags in
the top level, and decide what to pass to each sub-directory.

-- 
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