Re: [boost] Proposal for moving Boost to CMake

On Jun 18, 2017, at 6:05 PM, Rene Rivera wrote:

On Sun, Jun 18, 2017 at 4:09 PM, P F via Boost mailto:boost@lists.boost.org> wrote:

However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.

First.. Needing to upgrade cmake to deal with newer releases of Boost is, IMO, a design and implementation defect of cmake.

How is it a defect of cmake? How can cmake know the usage requirements for boost libraries when boost doesn’t make that available?

Second.. Why not use something like Conan that doesn't care about what build system your dependencies use and will adjust to the build system you are using for your product?

Conan requires adding special function or macros to the cmake that don’t work with standalone cmake. This also makes it not work with other package managers that may want to build the library. We could write conditionals around the conan functions, but then it feels like we are supporting two buildsystems. Hopefully, in the future, conan will fix this so that there is no need for modifications to the cmake file. Also, cget can work with other build systems as well by providing a cmake file that can translate the cmake toolchain to the other build system. It already provides this support for boost, so you can build boost with: cget install -X boost https://downloads.sourceforge.net/project/boost/boost/1.64.0/boost_1_64_0.ta... If we support modular builds like I showed(where I can clone a library and then call `b2 install`), then cget could install libraries modularly: cget install -X boost boostorg/predef However, since predef is header-only, you can currently install it like this: cget install -X header boostorg/predef Of course, none of this supports the usage requirements. If there is a way to retrieve this information during a build of boost, I can update cget’s boost script to convert this to cmake packages or pkgconfig.