Boost logo

Boost :

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-14 09:55:00


> On Apr 14, 2016, at 8:31 AM, Paul Fultz II <pfultz2_at_[hidden]> wrote:
>
>
>> On Apr 14, 2016, at 6:01 AM, Peter Dimov <lists_at_[hidden]> wrote:
>>
>> P F wrote:
>>
>>> Does lightweight_test depend on something else? If so, lightweight_test could be moved to a separate module. This way Boost.Config would depend on Boost.LightweightTest and Boost.Core would depend on Boost.Config and Boost.LightweightTest.
>>
>> lightweight_test depends on Config for BOOST_NO_EXCEPTIONS, used in BOOST_TEST_THROWS. I thought about moving it to Assert, which seems like a logical place for it, but Assert depends on Config for BOOST_LIKELY.
>
> Since Boost.Config only uses it for BOOST_TEST, it easy enough to just write:
>
> #define BOOST_TEST(x) if (!(x)) { std::cout << “FAILED”; std::abort(); }
>
> However, Boost.Config's test still depends on type traits.

Well actually Boost.Config could use Boost.TypeTraits when BOOST_NO_CXX11_STD_ALIGN is defined, otherwise it could use the standard type traits. This would at least get rid of the cycle on modern compilers.

>
>>
>> But, as I said, the main obstacle would be Boost.Test.
>
> True, however, at least the core libraries of boost can be fully cycle-free. So newer libraries can be built using the core utilities without having to deal with cycles.
>
>>
>> I'm not quite sure that eliminating cycles in test dependencies is worth its while. There is no actual cycle. Config's tests depend on Core, which depends on Config's headers, not its tests.
>
> If boost ever wants to support the standard `make && make check && make install` with cmake then this will be a cycle.
>
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk