Re: [HELP WANTED] toplevel configure, make, and RANLIB

[Geoff Keating <geoffk at geoffk dot org>]

Nathanael Nerode <neroden@doctormoo.dyndns.org> writes:

> I'm trying to autoconfiscate the top level directory and it's going
> well.  I am, however, running up against one extremely irritating
> problem: RANLIB.
> 
> RANLIB is handled in a very funny way right now.
...
> I can't see any way at all to replicate this monstrosity using Autoconf.
> Nor do I really want to, since I suspect it's not entirely correct.
> 
> However, I'm at a loss as to what the correct thing to do is.  So I need
> help.  
> 
> It's easy to either pass down RANLIB *all* the time, or *none* of
> the time (unless it's on the MAKE command line).  This 'some of the
> time' thing is ugly and I do not want to replicate it.

Good!

Yes, pass RANLIB down all the time.

RANLIB is a ranlib that runs on the build machine and works on host
binaries.  There's also a TARGET_RANLIB that runs on the build machine
and works on target binaries (for the runtime libs).  There could be a
BUILD_RANLIB, too, which would be a native ranlib on the build machine
(for building the build machine's version of libiberty), but I think
that's special-cased.

> * Should RANLIB be set and passed down unconditionally if build!=host?
>   What, in fact, should RANLIB be if build!=host?  Can autoconf in the
>   the subdiectories deal with this case?  Should it be able to?

If build != host, RANLIB should be ${host_alias}-ranlib, if that
exists, or 'true' (or ':') if it doesn't.

> * When build=host, is autoconf in the subdirectories clever enough to
>   always handle the special cases where ranlib isn't needed?  The
>   special case where it's 'ar ts'?  Is this last case important?

If you want to pass it down always, then if it's not needed just pass
down 'true' or ':'.

> * When build=host, is it better to set ranlib from the top level and
>   cause its value to be unified, rather than different per
>   subdirectory?  What might this break?  (Lots of things?)

It shouldn't break anything.  I don't think we want to try supporting
building parts of the tree with different sets of tools.

The exception to this is when building the target libraries and
binutils in the same tree, in which case you want to set
TARGET_RANLIB=../binutils/ranlib always.

> Some answers to these questions might help me get past this roadblock.
> 
> At the moment this is actually the nastiest thing holding up my
> autoconfiscation; I've got tentative solutions for pretty much
> everything else.
> 
> Thanks in advance,
> Nathanael

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>