Re: [boost] Boost CMake update

Subject: Re: [boost] Boost CMake update
From: paul (pfultz2_at_[hidden])
Date: 2017-10-02 19:56:40

On Mon, 2017-10-02 at 10:33 -0700, Rene Rivera wrote:
> On Mon, Oct 2, 2017 at 9:59 AM, paul via Boost <boost_at_[hidden]>
> wrote:
> > On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:
> > > On 10/2/17 8:27 AM, paul via Boost wrote:
> > > >
> > > > On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:
> > > >
> > > > Thats what is being done.
> > > >
> > > > >
> > > > >
> > > > > If that passes and is accepted
> > > > >
> > > > > b) Apply to all the libraries desired.
> > > > No, apply to all libraries period, as authors of upstream libraries
> > > > shouldn't
> > > > hold back a library from moving to cmake.
> > > I think it would be unwise to presume that you can enforce this.
> > 
> > I believe that is what the SC decision was about.
> What I believe Robert's, and others, point on this is that the SC can make
> pronouncements as to how things have to be. But library authors are free to
> ignore such pronouncements. As it's *their* libraries. Hence unless you
> convince them of concrete benefits over what they have now you aren't going
> to make a lot of forward progress. Just remember that programmers tend to be
> inherently lazy (except for Vinnie).

Yes, which is why I am generating an initial implementation of cmake, instead
of relying on each individual author.

> 
> > > Such 
> > > approaches have failed in the past. You would be better served by 
> > > focusing on creating a system whose benefits are sufficiently
> > compelling 
> > > that the question of imposing the new system doesn't arise.  
> > 
> > One of the important use cases to support cmake in boost, is to move away
> > from
> > problematic find modules for `find_package`. 
> > 
> > For example, you may want to support cmake in Boost.Serialization, but
> > Boost.Iterator does not desire to update to cmake. So now you will need to
> > create a Findboost_iterator.cmake module for Boost.Serialization. Not only
> > that, but any downstream users of Boost.Serialization will need to a copy
> > of
> > the Findboost_iterator.cmake module. Now when the usage requirements for
> > Boost.Iterator changes all these modules will be wrong.
> Or you could just use conan, and not force any particular build system on
> anyone.

Or rather you are replacing a build system with another. Or in the case of
cmake, replacing a a meta-build system with a meta-meta build system(that also
happens to be a package manager). 

It doesn't integrate well with cmake. You can't do `add_subdirectory` with
packages that conan provides. 

Also, if you are in the 'install' camp, conan doesn't properly tell cmake
where the dependencies are. This is why you have to add special conan cmake
functions to your cmake like `conan_basic_setup`, which still has problems.

If you use any of cmake's find_* command, it will no longer work because even
with `conan_basic_setup`, cmake still doesn't know where your dependencies
are.

Furthermore, adding `conan_basic_setup` to your cmake, you are no longer
supporting cmake users. You could add an additional `if` or put the conan
logic in a python file to support cmake users and conan, but now you are
supporting two build systems.

> 
> > With the large number of libraries in boost, having boost half-implemented 
> > in
> > cmake will just be a nightmare for users. They will need to figure out
> > which
> > libraries have cmake support and which ones need find modules. They will
> > need
> > to fix the modules on their own when the usage requirements for non-cmake
> > libraries change. 
> Or you could tell users that conan is the public interface to Boost and not
> force a particular build system on anyone. 
> 
> > Also, a lot of the libraries are very intertwined, so its not really
> > possible
> > to update to cmake piecewise. For example, to implement the build and
> > tests in
> > cmake for Boost.Config, we need cmake support for tr1, core, type_traits,
> > and
> > detail, which these libraries already depended on Boost.Config as well.
> The suggestion has been made before that it's perfectly possible to provide
> a build system agnostic interface to testing and other aspects of building
> libraries. 

It is, but the closest implementation I have seen of this is cmake.

.