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