2015-06-16 10:12 GMT+02:00 Vladimir Prus
condition appears unnecessary and problematic. There is no chance of ambiguity between ARM and MIPs variants. Do you see any issues if <abi> property is removed from condition for all ARM variants?
At the moment the rules in context/build/Jamfile.v2 for ARM are over specified, e.g. architecture and address-mode are sufficient. I keep <abi> for ARM in order to be consistent with the rules for the other architectures in the Jamfile. That means it is always a problem to determine the correct ABI and binary format for a certain compilation.
boost.context determines the default values for ABI/binary-format on the
values returned by 'os.name' and 'os.platform'. I don't know another way for reliable ABI/binary-format detection in boost.build.
For avoidance of doubt, do you mean "boost.build" specifically? From your first observation, it appears that it's hard to detect ABI in any build system not using mind reading technology?
I use features os.name and os.platform from boost.build (boost.config?) to set ABI and binary format (e.g. the default values).