On Sun, Jul 30, 2017 at 1:59 PM, Louis Dionne via Boost <boost@.boost> wrote:
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.
Currently there is no requirement that some or all Boost libraries are "usable individually."
* What is the definition of "usable individually?"
Outside of the superproject. The definition I'm using is that the following workflow should work: .. install prerequisites for some-library into some ${PREFIX} .. git clone some-library cd some-library mkdir build cd build cmake .. -DCMAKE_PREFIX_PATH=${PREFIX} cmake --build . # The library builds and uses the dependencies installed at the # specified location. These dependencies can be set up manually # or using a real package manager (Conan, cget, whatever).
* It seems we have added a stealth requirement. Cmake integration is not enough now?
Please read my message again. I said we should NOT tackle this as part of the CMake effort. I just said that any solution that makes this impossible is bonkers (IMO) since it (1) is already required by some libraries that ship individually (2) goes against the best practices for CMake such as in [1] (3) would prevent us from having a truly modular Boost in the future Also, doing this properly only requires saying `find_package` for the dependencies that a library has, which we could argue is good even if only as a documentation of the "cost" of a library. I really don't see how `find_package` makes anything more difficult, as it's a no-op for superproject builds anyway. Louis [1]: https://youtu.be/bsXLMQ6WgIk?t=55m48s -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-tests-with-cmake-tp4697568p4697615.... Sent from the Boost - Dev mailing list archive at Nabble.com.