Re: [PATCH] Libraries' configure scripts should not read config-ml.in when multilib is disabled

[John Ericson <john.ericson@obsidian.systems>]

On 07/30/18 19:48, Joseph Myers wrote:
> On the contrary, I think an important principle here is that non-multilib
> and multilib builds follow the same code paths as far as possible, with
> the multilib variables just set to trivial values (modulo osdirname) in
> the case of a non-multilib build - a non-multilib build should be building
> libraries exactly the same, with the same logic and the same variable
> settings, as the default multilib in a multilib build.
I whole-heatedly agree with that principle. [FWIW, I've taken a similar 
approach with keeping the cross and native compilation code paths as 
close as possible. This is why I'm building the libraries separately in 
the first place.]

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.

John