Re: [boost] Boost CMake update

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

On Mon, 2017-10-02 at 10:16 -0700, Robert Ramey via Boost wrote:
> On 10/2/17 9:59 AM, paul via Boost 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.
> Agreed.  That's why it's flawed.
> 
> > 
> > One of the important use cases to support cmake in boost, is to move away
> > from
> > problematic find modules for `find_package`.
> <snip>
> 
> Interesting, I look forward to seeing this topic discussed in the review.
> 
> > 
> > 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.
> Also very interesting.  Doesn't bode well for a successful 
> implementation.  But we're anxious to have a look.

This email update was the start of successful implementation, so I disagree..

> 
> > 
> > 
> > > 
> > > To me this
> > > is the main benefit of having such tooling ideas go through the boost
> > > review process.
> > The system is already defined by cmake, adn BCM doesn't plan to change
> > that..
> > The modules are just there to improve the cmake's workflow in the context
> > of
> > boost.
> Hmmmm - so you're saying what?  That there is nothing to be gained by 
> the boost type of review process? 

I am not saying there shouldn't be reviewed, because we want to make sure it
is sufficient for developers and users.

> That it's just a question telling 
> developers to "turn on" CMake.  That every aspect of build/test/post 
> results is baked into CMake and there is no ambiguity about how to use 
> it in this context.  Having spent significant amount of time with CMake 
> myself, this would be a surprise to me.

There is a effective workflow with cmake that can help cover many different
use-cases as outlined by Daniel Pfeifer's Effective CMake talk, and I don't
think we should stray from that.

> 
> If you really think this, we can drop the whole idea of boost style 
> review and just stay with the current situation.  This is that Boost 
> Steering committee makes a pronouncement, and developers ignore it.

I dont think this.

.