This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

[HELP WANTED] toplevel configure, make, and RANLIB


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.
* if 'host' is not one with an mh-(host) fragment in top level config,
RANLIB is not passed down.
* if 'host' has an mh-(host) fragment, and build=host, the RANLIB
defined in the fragment is passed down.  (This is always 'true', expect
for two cases where it's 'ar ts' and '@:')
* if 'host' has an mh-(host) fragment, and build!=host,
${host-alias}-ranlib is passed down.
* if 'host' has an mh-(host) fragment, and RANLIB was exported to
toplevel configure, that's passed down instead.
* If RANLIB is defined on the top level Make command line, that's passed
down (the only sane case here!)

RANLIB_FOR_TARGET tries binutils/ranlib, then
* if host=target and RANLIB is passed down (from above), uses that
* if host=target and RANLIB isn't passed down, uses 'ranlib'
* if host!=target, applies $(program_transform_name) to 'ranlib'

All directories which use RANLIB set it *if it isn't passed down*,
but most of them accept a passed down version.

You can also look at the situation as these two cases:
* 'target' directories.  These always get a ranlib passed down to them,
which first tries binutils/ranlib, and then:
* if host!=target, applies $(program_transform_name) to 'ranlib'
* otherwise, if RANLIB from command line, uses that;
* otherwise, if there is an mh-(host) fragment and build!=host, uses
'${host-alias}-ranlib'
* otherwise, if there is an mh-{host) fragment, uses the RANLIB from the
fragment
* otherwise, if the subdir sets RANLIB in its own special way, uses that
* otherwise, if there's no mh-(host) fragment, uses 'ranlib'


* 'host' directories.  These don't get a RANLIB passed down to
them, unless there's an mh-(host) fragment.
* if there's an mh-(host) fragment and build!=host, uses
'${host-alias}-ranlib'
* if there's an mh-(host) fragment and build=host, uses the RANLIB from
the fragment
* if there's no mh-(host) fragment, each subdir sets RANLIB in its own
special way.

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.

* 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?
* 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?
* 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?)

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


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