configure: improve inference of compiler flags for pb builds #829
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A follow-up to #828
When building an pb variant like
tpb64l
, and even when building for a platform without native-code support, the "configure" script may still be able to infer suitable C compilation and linking flags for the kernel. For example, configuring with just-m=tpb64l
on ppc64l Linux should pick up good compiler and linker flags.An
--os=...
flag can override inference in "configure" in case it's not correct, which might be needed for cross compilation of pb variants.With these changes,
-m=pb
by itself is now equivalent to--pb
, instead of triggering an error to say that--pb
must be used. Using-m=pb
is not equivalent to--pb
in all cases, since--pb --threads
is like-m=tpb
, but-m=pb --threads
would be an error due to the mismatch between an explicitpb
machine type and--threads
flag. The interactions are subtle, but I'm hopeful that "configure" now does the right thing in more cases.