Re: [boost] Boost tests with cmake

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 
only libraries.

> 
> 
>> 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.
> 
> Louis