[test] BOOST_PP_VARIADICS is defined twice
Hi, For some reason Boost.Test defines the BOOST_PP_VARIADICS macro, which, I believe, is a macro defined by Boost.Preprocessor. This results in build errors as can be seen here: http://www.boost.org/development/tests/develop/developer/output/teeks99-01b-... I think Boost.Test should not define BOOST_PP_VARIADICS and rely on Boost.PP for that. In any case, BOOST_PP* is not the namespace of Boost.Test.
Le 16/10/15 11:22, Andrey Semashev a écrit :
Hi,
For some reason Boost.Test defines the BOOST_PP_VARIADICS macro, which, I believe, is a macro defined by Boost.Preprocessor. This results in build errors as can be seen here:
http://www.boost.org/development/tests/develop/developer/output/teeks99-01b-...
I think Boost.Test should not define BOOST_PP_VARIADICS and rely on Boost.PP for that. In any case, BOOST_PP* is not the namespace of Boost.Test.
Refers to this thread: - http://lists.boost.org/boost-build/2015/10/28334.php And those two in particular: - http://lists.boost.org/boost-build/2015/10/28344.php - http://lists.boost.org/boost-build/2015/10/28351.php (this is what is causing the errors apparently). So I will guard the enforcement of BOOST_PP_VARIADICS=1 in case this one is already defined. Boost.Test can define BOOST_PP_VARIADICS=1 in case the compiler supports cxx11_variadic_macros (which is not cxx11 specific, see http://lists.boost.org/boost-build/2015/10/28344.php). It is right now guarded for clang and gcc >= 4.8, which are the environments I have for our internal tests. Thanks for the feedback. Raffi
On 16.10.2015 12:30, Raffi Enficiaud wrote:
Le 16/10/15 11:22, Andrey Semashev a écrit :
Hi,
For some reason Boost.Test defines the BOOST_PP_VARIADICS macro, which, I believe, is a macro defined by Boost.Preprocessor. This results in build errors as can be seen here:
http://www.boost.org/development/tests/develop/developer/output/teeks99-01b-...
I think Boost.Test should not define BOOST_PP_VARIADICS and rely on Boost.PP for that. In any case, BOOST_PP* is not the namespace of Boost.Test.
Refers to this thread: - http://lists.boost.org/boost-build/2015/10/28334.php
And those two in particular: - http://lists.boost.org/boost-build/2015/10/28344.php - http://lists.boost.org/boost-build/2015/10/28351.php (this is what is causing the errors apparently).
So I will guard the enforcement of BOOST_PP_VARIADICS=1 in case this one is already defined.
You can't guarantee the order of inclusion of Boost.Test and Boost.PP headers. So, if I understand it right, by adding that check you essentially make the interface inconsistent. If you have the non-variadic implementation anyway, why do you want this inconsistency?
Le 16/10/15 11:40, Andrey Semashev a écrit :
On 16.10.2015 12:30, Raffi Enficiaud wrote:
[snip]
So I will guard the enforcement of BOOST_PP_VARIADICS=1 in case this one is already defined.
You can't guarantee the order of inclusion of Boost.Test and Boost.PP headers. So, if I understand it right, by adding that check you essentially make the interface inconsistent. If you have the non-variadic implementation anyway, why do you want this inconsistency?
PPvariadic allows to use some of the features introduced on boost.test v3 that eg. boost.log is not using. I can enforce the support of PPvariadic for the compilers I know that support variadic, so that it brings a subset of v3 for those compilers, without the user taking care of that. I will clarify that point in the doc, but I do not see much of inconsistencies there: - variadic already defined => up to the user (either inclusion order or enforcement). - variadic not defined => up to boost.test.v3 But again this concerns features that are in boost.test.v3 and not in boost.test.v2. The fix should be in develop once my runners are green (maybe half an hour). Raffi
On 16.10.2015 12:53, Raffi Enficiaud wrote:
Le 16/10/15 11:40, Andrey Semashev a écrit :
On 16.10.2015 12:30, Raffi Enficiaud wrote:
[snip]
So I will guard the enforcement of BOOST_PP_VARIADICS=1 in case this one is already defined.
You can't guarantee the order of inclusion of Boost.Test and Boost.PP headers. So, if I understand it right, by adding that check you essentially make the interface inconsistent. If you have the non-variadic implementation anyway, why do you want this inconsistency?
PPvariadic allows to use some of the features introduced on boost.test v3 that eg. boost.log is not using. I can enforce the support of PPvariadic for the compilers I know that support variadic, so that it brings a subset of v3 for those compilers, without the user taking care of that.
I will clarify that point in the doc, but I do not see much of inconsistencies there: - variadic already defined => up to the user (either inclusion order or enforcement). - variadic not defined => up to boost.test.v3
My point is that the user can't rely on these new features if he doesn't use the compiler in C++11 mode because he may include headers in the wrong order. Relying on inclusion order in the first place is a terrible idea, to my mind. You should just use what Boost.PP allows you to use and not try to force its configuration. It's not your business to do that. If anything, it should be the user's choice, not yours. Although not related to Boost.PP, I had a similar situation with Boost.Log and Boost.ASIO - the default configs of the two libraries were conflicting and I proposed to force Boost.Log config on Boost.ASIO[1]. The result of the discussion was that a library should not impose config choices on another library.
The fix should be in develop once my runners are green (maybe half an hour).
Thanks for the quick fix. [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258870
participants (2)
-
Andrey Semashev -
Raffi Enficiaud