Re: Partial autoconf transition thoughts

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jun 09, 2003 at 07:34:00PM -0300, Alexandre Oliva wrote:
> 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.

As I told Alex on IRC, I was looking at the upgrading-from-2.13 section
of the manual (where it isn't clear that this is deprecated) and the
generated configures (where it obviously works).

My instinct is to rely upon this deprecated feature of 2.57 as it is
easy to remove once we have transitioned all directories, which I
expect to be fairly quick.

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

Nope, pilot error on my part.  It works fine here.  I even did both
autoconf and automake in the gas directory.

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

Has never happened to me.

> > 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 understand that, and how to do it.  But _what_ different arguments do
you want?  What's the mapping?

When I sat down to work out the mapping I produced my original table
and decided I didn't need a mapping at all.

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

I jut retried these:
--build=i686-linux --host=i686-linux
--build=i686-linux
--host=i686-linux
i686-linux
<none>

All five worked fine.  Perhaps I'll do libiberty next.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer