|
Boost : |
Subject: Re: [boost] Boost CMake update
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-10-02 17:16:22
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.
>
>> 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? 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.
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.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk