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 explicit pb machine type and --threads flag. The interactions are subtle, but I'm hopeful that "configure" now does the right thing in more cases.
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.