Subject: Re: [boost] Boost tests with cmake
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-30 22:05:09
On 7/30/2017 4:59 PM, Louis Dionne via Boost wrote:
> Edward Diener wrote:
>> I do not understand two issues:
>> 1) Why does find_package have to be used for header-only libraries at
>> all ? Or what does it buy you in CMake terms for header-only libraries?
> I'm assuming you're referring to using find_package as opposed to just
> saying `-I path-to-library/include`.
> Header-only libraries have requirements just like built libraries. For
> example, a header-only library could require you to use -std=c++14, or to
> link with some non-header-only library when you depend on it. By properly
> declaring your header-only library and its requirements (in terms of
> dependencies, compiler options, macro definitions, whatever), and by using
> find_package + target_link_libraries, you inherit the requirements of the
> header-only library.
This is understandable but the vast majority of the Boost libraries are
header only libraries whose only dependencies are other Boost header
only libraries and possibly C++ standard headers. Some of these
libraries may well enforce certain levels of C++ standards but this is
usually done in the code and with checking via the config library, or
possibly the predef library, that these standards are met. If they are
not met a compiler error occurs and of course any of these restrictions
should also be documented.
What I am arguing is that the move to CMake should go by steps. The
first step is:
1) Libraries which are built, even if just partially, into shared/static
libraries need to have their build with CMake.
2) All libraries need to have their tests with CMake.
3) All libraries that build their documentation via a jamfile need to
have their documentation built with CMake.
4) All libraries that run examples with a jamfile need to have those
examples run with CMake.
Once Boost can do this, so that each Boost Build task which end-users
might want to use has a CMake equivalent, Boost can ship with CMake
support. After that if library developers, or people who have write
access to a library, want to further add find_package support for
individual header only libraries I can see that happening. But if we go
ahead doing this when we do not really need to do it, we will end up
creating a great amount of unnecessary work for those who support header
>> 2) Why is it assumed that individual Boost libraries can be shipped when
>> there is no current or proposed version control to insure that some
>> individual Boost library shipped by itself will actually work properly
>> with some other individual Boost library shipped by itself that is its
>> dependent ?
> That's a thornier question, actually. What Hana does is simply that it
> tests itself against all Boost versions up to the current trunk. I don't
> think we want this as a blanket policy, however.
>> Is there an encompassing solution in CMake to this problem?
> When/if we decide on a compatibility policy across different libraries, I
> think we may be able to use `find_package` with custom version compatibility
> checking to implement it.
> All that being said, I'm not saying we should try to make all Boost
> libraries usable individually as part of the CMake effort. We should not.
> However, I think any solution that makes this impossible is unacceptable,
> both because it bars us from doing it in the future and because some
> libraries (such as Hana) require it today.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk