[contract] ready to release
Hello release managers & all, Boost.Contract in master is ready to be added to the next Boost release (regression tests pass, docs are updated, etc.). What do I have to do to put https://github.com/boostorg/contract.git master into Boost release 1.67? Thank you. --Lorenzo
Hello all,
On Tue, Jan 9, 2018 at 7:29 AM, Lorenzo Caminiti
Boost.Contract in master is ready to be added to the next Boost release (regression tests pass, docs are updated, etc.).
I turns out the Boost inspect program reports the following: boost/contract/check.hpp: (line 102) Apple macro clash: check boost/contract/detail/type_traits/mirror.hpp: (line 29) Apple macro clash: check http://boost.cowic.de/rc/docs-inspect-develop.html#contract Are these a real issues? Boost.Contract uses 'check' as: boost::contract::check c = boost::contract::function().precondition(...); I could of course renamed that to 'check_' but it looks ugly... Will a class named check in boost::contract namespace really clash with Apple defined names? Or this only an issue for ancient Apple compilers and I no longer have to worry about it? Thanks. --Lorenzo
AMDG On 01/10/2018 12:45 PM, Lorenzo Caminiti via Boost wrote:
I turns out the Boost inspect program reports the following:
boost/contract/check.hpp: (line 102) Apple macro clash: check boost/contract/detail/type_traits/mirror.hpp: (line 29) Apple macro clash: check http://boost.cowic.de/rc/docs-inspect-develop.html#contract
Are these a real issues? Boost.Contract uses 'check' as:
boost::contract::check c = boost::contract::function().precondition(...);
I could of course renamed that to 'check_' but it looks ugly...
check is a function-like macro, so it won't affect that particular usage. Expansion in the class definition can be blocked with BOOST_PREVENT_MACRO_SUBSTITUTION
Will a class named check in boost::contract namespace really clash with Apple defined names?
Namespaces don't affect macros, which is why we ended up adding this to inspect in the first place.
Or this only an issue for ancient Apple compilers and I no longer have to worry about it?
Also, I noticed one issue with your build/Jamfile. You should just link to /boost//system regardless of whether whether you're building a static or shared library. Putting /boost//system in the usage requirements does not guarantee that the libraries will be passed to the linker in the correct order. (In this case it works because "contract" is lexicographically before "system", but you really shouldn't rely on that behavior.) In Christ, Steven Watanabe
Hello Steven!
On Wed, Jan 10, 2018 at 12:03 PM, Steven Watanabe via Boost
On 01/10/2018 12:45 PM, Lorenzo Caminiti via Boost wrote:
I turns out the Boost inspect program reports the following:
boost/contract/check.hpp: (line 102) Apple macro clash: check boost/contract/detail/type_traits/mirror.hpp: (line 29) Apple macro clash: check http://boost.cowic.de/rc/docs-inspect-develop.html#contract
Are these a real issues? Boost.Contract uses 'check' as:
boost::contract::check c = boost::contract::function().precondition(...);
I could of course renamed that to 'check_' but it looks ugly...
check is a function-like macro, so it won't affect that particular usage.
True and in user code programmers can always use the `boost::contract::check c = ...` syntax so this is not an issue.
Expansion in the class definition can be blocked with BOOST_PREVENT_MACRO_SUBSTITUTION
Yes, this worked great and fixed my original issue.
Also, I noticed one issue with your build/Jamfile. You should just link to /boost//system regardless of whether whether you're building a static or shared library. Putting /boost//system in the usage requirements does not guarantee that the libraries will be passed to the linker in the correct order. (In this case it works because "contract" is lexicographically before "system", but you really shouldn't rely on that behavior.)
I see, I'm fixing this. Thank you! --Lorenzo
participants (2)
-
Lorenzo Caminiti
-
Steven Watanabe