On 5 Jun 2015 at 5:30, Edward Diener wrote:
I don't know what "the right approach" would be but this is one approach that does work easily, following the documentation I have written about it and added to the Boost.config documentation.
Firstly, this is a long overdue patch and I find it a hugely welcome development. Thank you Edward for taking the time to implement it.
If I have missed any Boost libraries which have a close C++ standard equivalent just tell me and I will add it with some added tests for that particular library.
I didn't see system_error?
5) I wanted to push it to 'develop' and let others use it and add the per library PR's to test it. If it was found to be flawed or could be better in any way I could then change it on 'develop', and if people were satisfied with it as a workable solution it could eventually be merged to 'master'. If not it could be easily removed if necessary since it exists in its own header files apart from the rest of Boost.config. Even its documentation is a separate Boost.config .qbk file.
Here's a crazy idea: If Boost.Build is in >= C++ 11 build mode, turn all these macros on by default. That should ease testing enormously. Build needs to gain an official C++ 11 build mode first though. Something where libraries in their Jamfile can say "I can only compile with C++11 or better, so if not >= C++ 11 then ignore this library during build".
If there are better interoperable systems I would love to hear about them. But for me personally any system where I have to jump through hoops simply to be able to write code which works whether I am using a Boost library or its C++ standard library equivalent, will not be worth it.
I think this support is a great first step to making Boost less obsolete in a C++ 11 world. It doesn't solve all the other problems Boost has, but it's still a huge improvement.
Questions, concerns etc are welcome.
My only real worry is the ABI problems. You need to permute the symbols being linked to avoid config mismatches colliding in an unhelpful way. Perhaps for each config macro have during build the library output an extern dll visible empty function with a mangled name representing the config. On use, import and use that function. This should generate link errors if one is trying to use a config against a binary not built the same way. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/