Re: [boost] Proposal for moving Boost to CMake

On Jun 16, 2017, at 11:54 PM, David Sankel wrote:

On Sat, Jun 17, 2017 at 12:34 AM, P F mailto:pfultz2@yahoo.com> wrote:

...

On Jun 16, 2017, at 11:24 PM, David Sankel via Boost mailto:boost@lists.boost.org> wrote:

On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost < boost@lists.boost.org mailto:boost@lists.boost.org> wrote:

...

On 6/16/17 4:44 PM, David Sankel via Boost wrote:

...

* Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each particular library? Who would re-write and maintain this FindBoost as the current one is not up the task. Getting this right - or even better is not a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is relatively straightforward. The implementation for the Boost-source version of this library would look at the COMPONENTS argument and, based on that, add_subdirectory the source for the particularly requested library. The CMakeLists.txt file would be author maintained and provide its corresponding target (e.g. boost::thread).

Thats not the the way `find_package` works at all. The `find_package` is used to find packages installed, it should never go out and build libraries.

I don't know where you get that impression (again, see the video I linked to earlier).

None of the find modules do this, nor do libraries that provide config cmake. In fact, the video shows a lot of non-standard ways of using cmake, which is what you are proposing we avoid, and I agree with.

This is, indeed, the only way to write packages that can be built with already-installed binaries or together with the source code of their dependencies.

But you never write packages, rather you ignore the packages, like this: set(as_subproject Foo) macro(find_package) if(NOT "${ARG0}" IN_LIST as_subproject) _find_package(${ARGV}) endif() endmacro() add_subdirectory(Foo) add_subdirectory(App) This makes `find_package(Foo)` do nothing as `Foo::Foo` is part of the project. This way projects can be written to support both modular and superproject build without changing the build scripts, and without needing to use `if(NOT TARGET)` hacks.

It is a very important property to have in a build system for large-scale development.

It is very important for boost to be able to support `add_subdirectory` builds. However, hijacking `find_package` to call `add_subdirectory` is the wrong approach and goes against cmake’s workflow. The approach I outlined is what is presented in Daniel Pfeifer’s Effective Cmake talk(although I was aware of this before Daniel’s talk).