Re: [boost] [test] BOOST_PP_VARIADICS is defined twice

Subject: Re: [boost] [test] BOOST_PP_VARIADICS is defined twice
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-10-16 06:17:32

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