Re: Understanding Multilibs ;-)

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 28, 2003, neroden@twcny.rr.com (Nathanael Nerode) wrote:

> So, I decided to take a crack at moving multilibbing to the top level.

Wheee! :-)

> What I'm getting confused by at first is how the list of multilibs is 
> generated.

config-ml.in configures only the multilibs that are deemed valid.
Then, the Makefile stub that goes in every library's top Makefile
iterates over all multilibs the compiler knows about, skipping those
whose directories don't exist (assuming they aren't there because they
weren't configured)

If you're to move this logic to the top level, make sure you follow
the logic in config-ml.in, and not the simplified logic that
config-ml.in adds to the primary multilib of every target lib (that we
want to get rid of in this process, right?)

Also, beware of some problems you'll run into:

- Ideally, we'd like to have Makefile dependencies in the top level
  for every combination of library/mutlilib, such that we could do
  something like `make all-target-<multilib>-libstdc++-v3, and have
  only libstdc++-v3's dependencies built for multilib.

  Unfortunately, this is very tricky to accomplish.  First, because
  you can only tell the set of multilibs after the compiler is build,
  so you'd have to change the top-level Makefile somehow while it's
  already running, i.e., you can't do it.

  The solution I've been thinking of for the past few days goes like
  this: we introduce a new Makefile in <target_alias>, that will
  contain the actual target libraries' dependencies, instantiated for
  every multilib.  We'd have a top-level Makefile target
  target-Makefile or so that would depend on all-gcc and would
  construct such a Makefile.  all-target would then depend on
  target-Makefile, and do make -C <target> all.

  We could still have all-target-<lib> in the top level, redirecting
  to target/Makefile, but it's trickier to get right, because of
  parallel makes.  We still need accurate dependencies of target
  libraries in the top level Makefile, but they must redirect to
  targets that iterate over all multilibs but that do *not* have
  dependencies.  Such targets should only be used from the toplevel
  Makefile.  The idea of not having dependencies is to make sure that,
  even though say both libstdc++ and libobjc depend on newlib, we
  don't go through newlib twice in parallel when we descend into
  target/Makefile for libstdc++ and libobjc in parallel.

Lemme try to give an example:

toplevel/Makefile:
configure-target-Makefile: all-gcc \
  # plus dependencies to reconfigure in case the set of multilibs changes
        create or update $(target)/Makefile

all-target: all-target-Makefile
        cd $(target) && $(MAKE)

configure-target-<lib>: configure-target-Makefile
        cd $(target) && $(MAKE) configure-<lib>-nodeps
all-target-<lib>: configure-target-<lib>
        cd $(target) && $(MAKE) all-<lib>-nodeps



<target>/Makefile:
all:

configure-<lib>: configure-<lib>-<multilib>...
all-<lib>: all-<lib>-<multilib>...
        
configure-<lib>-<multilib>: lib's configure deps for multilib
        $(MAKE) configure-<lib>-<multilib>-nodeps
all-<lib>-<multilib>: configure-<lib>-<multilib> lib's build deps for multilib
        $(MAKE) all-<lib>-<multilib>-nodeps

configure-<lib>-<multilib>-nodeps:
        mkinstalldirs $(multilib)/$(lib)
        cd $(multilib)/$(lib) && configure
all-<lib>-<multilib>-nodeps:
        cd $(multilib)/$(lib) && $(MAKE)

configure-<lib>-nodeps: configure-<lib>-<multilib>-nodeps...
all-<lib>-nodeps: all-<lib>-<multilib>-nodeps...

all: all-<lib>...


I *think* this design should work, enabling multilibs to be configured
and built in parallel, and also to enable users to choose a select set
of multilibs to build or install, interacting with the target-specific
Makefile.

We'll probably need an autogen-generated Makefile fragment to which
we'd apply autoconf substitutions on a per-multilib basis.

Cool, eh? :-)

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