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.
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 -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-tests-with-cmake-tp4697568p4697609.... Sent from the Boost - Dev mailing list archive at Nabble.com.