On 6/16/2015 11:30 AM, Oliver Kowalke wrote:
2015-06-16 10:12 GMT+02:00 Vladimir Prus
: Correct, but we're talking about ARM right now - there, adding <abi> to
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.
It seems to me that consistency between different architectures forces users of ARM to specify abi, which is not great. I would recommend dropping abi requirements there.
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).
These tell you host os. I doubt that could be helpful to determine ABI really. - Volodya