On Mon, 30 Jul 2018, John Ericson wrote: > That said, it is my tentative understanding that the point of having config-ml > is to cordon-off all the necessarily-multilib-specific logic so it doesn't > pollute everything else. When that script isn't run, I think the Makefiles > already contain default "trivial values" for capitalized MULTI* variables > (which are the only ones actually used by the build itself), yielding > precisely that deduplication of code paths we both want.
Well, if there are unnecessary settings in Makefiles the obvious thing to do is to remove them. I think ideally config-ml.in wouldn't contain any conditionals at all on whether multilibs are enabled, and would run just the same whether they are or not, because in the multilib-disabled case -print-multi-lib should print the appropriate line for exactly one multilib, and everything should just follow through from that setting (--disable-multilib should be equivalent to multilibs enabled but only one present). (More clearly, I think the special handling in config-ml.in for various architecture-specific configure options should go away. I don't know why it's there, but multilib-related configure options should result in -print-multi-lib doing the right thing, so top-level doesn't need to do further manipulations on top of that.) To build libraries separately, you can configure at top level with some of the subdirectories or their configure scripts that you don't need removed to avoid them getting built as well, and with --disable-multilib, and with my proposal above for config-ml.in not itself checking for --disable-multilib you might also need CC_FOR_TARGET etc. set to a wrapper that overrides the output of -print-multi-lib. -- Joseph S. Myers jos...@codesourcery.com
