Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-17 06:23:08

> On Jun 16, 2017, at 11:54 PM, David Sankel <camior_at_[hidden]> wrote:
> 
> On Sat, Jun 17, 2017 at 12:34 AM, P F <pfultz2_at_[hidden] <mailto:pfultz2_at_[hidden]>> wrote:
> 
> > On Jun 16, 2017, at 11:24 PM, David Sankel via Boost <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
> >
> > On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost <
> > boost_at_[hidden] <mailto:boost_at_[hidden]>> 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).