CMake in Boost

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

CMake in Boost

Boost - Dev mailing list
Many have expressed the desire that Boost support CMake. The Boost Board
of Directors has emitted some sort of resolution to this effect - it's
been a year.

I would like to see progress in this direction.  To this end I propose
the following:

a) Boost announce that a review of proposals to incorporate CMake into
boost will be held in January 2019.  This will follow customary Boost
practices.

b) Those who are willing and able to submit code/documentation and
whatever else in necessary should do so before this date. I would
anticipate at least two such submissions.  As is the case with other
reviews, I would not exist such submissions to be totally complete.  But
I would expect that they include enough for reviewers to test and
practice with the proposed system.

c) Prior to this discussions can be held on the list regarding the scope
of such an effort.  The review manager will distill these discussions to
a statement of scope.  This will be posted around 30 October 2018.

I nominate myself (Robert Ramey) as review manager in this instance.

Why would I do this?

a) Boost needs this
b) I've never been a review manager
c) I'm a masochistic idiot.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: CMake in Boost

Boost - Dev mailing list
Hi Robert, all,

it's obvious that there is a wide range of opinions not only on CMake
itself, but also (and in particular) on what it means for Boost to
"support CMake". And while I'm happy to see that you are suggesting a
"Request for Proposals" rather than a "solution", I still think the
problem space is a bit ill-defined. Perhaps we need to talk a bit about
requirements first, which proposals need to meet to be eligible. (For
example, one requirement I'd insist on would be "the proposal must give
project maintainers enough latitude to decide themselves whether to
adopt the proposed solution", i.e. any monolithic solution would by
design be excluded.)

While I'm not a big fan of overly formal processes, I'm afraid that the
effort people put into such proposals will just lead to frustration as
things will stall again, eventually. And as long as we can't even come
to some basic agreement as to how to move forward (not even involving
technical aspects of any particular solution), I think it would be
irresponsible to invite people to submit proposals.

Sorry,

Stefan

--

       ...ich hab' noch einen Koffer in Berlin...
     


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: CMake in Boost

Boost - Dev mailing list
On 9/14/18 1:56 PM, Stefan Seefeld via Boost wrote:

> Hi Robert, all,
>
> it's obvious that there is a wide range of opinions not only on CMake
> itself, but also (and in particular) on what it means for Boost to
> "support CMake". And while I'm happy to see that you are suggesting a
> "Request for Proposals" rather than a "solution", I still think the
> problem space is a bit ill-defined. Perhaps we need to talk a bit about
> requirements first, which proposals need to meet to be eligible. (For
> example, one requirement I'd insist on would be "the proposal must give
> project maintainers enough latitude to decide themselves whether to
> adopt the proposed solution", i.e. any monolithic solution would by
> design be excluded.)
>
 > And as long as we can't even come
 > to some basic agreement as to how to move forward (not even involving
 > technical aspects of any particular solution), I think it would be
 > irresponsible to invite people to submit proposals.

Note:
c) Prior to this discussions can be held on the list regarding the scope
of such an effort.  The review manager will distill these discussions to
a statement of scope.  This will be posted around 30 October 2018.

> While I'm not a big fan of overly formal processes, I'm afraid that the
> effort people put into such proposals will just lead to frustration as
> things will stall again, eventually.

LOL - not if I'm running things.

Robert Ramey
>
> Sorry,

LOL - NP

>
> Stefan
>
> --
>
>        ...ich hab' noch einen Koffer in Berlin...
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

CMake in Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey
> via Boost
> Sent: Friday, September 14, 2018 10:27 PM
>
> b) Those who are willing and able to submit code/documentation and
> whatever else in necessary should do so before this date. I would
> anticipate at least two such submissions.
 
Just to be sure: You are not counting my batch of PRs as one of those submissions
right? Is there already some alternative proposal to BCM in the making?

Other than that, thanks for suggesting concrete dates and I'm looking forward
to the "scope" discussion.

Best

Mike


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: CMake in Boost

Boost - Dev mailing list
On 9/15/18 3:25 AM, mike via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Robert Ramey
>> via Boost
>> Sent: Friday, September 14, 2018 10:27 PM
>>
>> b) Those who are willing and able to submit code/documentation and
>> whatever else in necessary should do so before this date. I would
>> anticipate at least two such submissions.
>  
> Just to be sure: You are not counting my batch of PRs as one of those submissions
> right?

LOL - I am.  To be honest though I haven't even looked at them.  To me
merging in a batch of PRs related to CMake is a defacto proposal
presupposing what CMake should be doing in the context of Boost and an
implementation of same.

Is there already some alternative proposal to BCM in the making?

Paul Fultz made proposal about this time last year.

>
> Other than that, thanks for suggesting concrete dates and I'm looking forward
> to the "scope" discussion.

I think this is very important.  There's lots of things one could expect
to use CMake for in the context of boost.  Previous discussions seem to
spend a lot of time sorting things out among participants who have
diverse ideas about this.  If we are going to request proposals, its
much better to articulate what we hope to accomplish with this.  And we
can't reach some sort of consensus on this question, proposals won't be
comparable.  Also it's unfair to ask for proposals without specifying
requirements.

Right now, my goal is even more modest.  Its it possible that we could
get consensus on accepting the timeline and procedure I proposed - and
with my being appointed to lead it?

Robert Ramey

>
> Best
>
> Mike
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

CMake in Boost

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> Sent: Friday, September 14, 2018 10:27 PM
>
>
> Many have expressed the desire that Boost support CMake. The Boost Board
> of Directors has emitted some sort of resolution to this effect - it's
> been a year.
>
> I would like to see progress in this direction.  To this end I propose
> the following:
>
> a) Boost announce that a review of proposals to incorporate CMake into
> boost will be held in January 2019.  This will follow customary Boost
> practices.

Sounds good

>
> b) Those who are willing and able to submit code/documentation and
> whatever else in necessary should do so before this date. I would
> anticipate at least two such submissions.  As is the case with other
> reviews, I would not exist such submissions to be totally complete. But
> I would expect that they include enough for reviewers to test and
> practice with the proposed system.
>
> c) Prior to this discussions can be held on the list regarding the scope
> of such an effort.  The review manager will distill these discussions to
> a statement of scope.  This will be posted around 30 October 2018.

Not a lot of time till then, so here are my 2cents:

First of all, I don't think the whole thing is worth it if the goal isn't
to completely replace b2 as a top level build system. Now, that doesn't
mean that individual libraries can't use whatever build system they want
internally (cmake can call any build command you want), but if there isn't
at least one common way to run the build and test and to communicate
dependencies, you can essentially say goodbye to a common release management
etc. As I said previously, cmake is by far the most common cross-platform
(meta-) build system out there, which has the nice side-effect that most
other build systems, IDEs and package managers have support for it.  

Now, a submission should have two parts:
1) A description on a plain/native cmake level what the interface to a
   c++library (on a build system level) should look like:
   How can the build of a library be triggered? How can the tests be run?
   What naming scheme should be used? What are common configuration variables
   that should be respected? How should boost internal dependencies be found /
   searched? ...
   If that interface is specified, everyone can implement it the way he/she prefers
2) A library that simplifies the implementation of the aforementioned
   interface as much as possible

I'm not saying that the first part can't be a byproduct of the second, they
should be documented and evaluated separately instead of saying "your c++
library's build process has to be compatible to whatever "my cmake library"
does. As was mentioned multiple times, individual boost libraries need to
become more independent of each other, so forcing everyone to depend on a
common cmake library is a step in the wrong direction.

>
> I nominate myself (Robert Ramey) as review manager in this instance.

You have my vote

Best

Mike


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: CMake in Boost

Boost - Dev mailing list
On 9/27/18 11:23 AM, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost


>> b) Those who are willing and able to submit code/documentation and
>> whatever else in necessary should do so before this date. I would
>> anticipate at least two such submissions.  As is the case with other
>> reviews, I would not exist such submissions to be totally complete. But
>> I would expect that they include enough for reviewers to test and
>> practice with the proposed system.
>>
>> c) Prior to this discussions can be held on the list regarding the scope
>> of such an effort.  The review manager will distill these discussions to
>> a statement of scope.  This will be posted around 30 October 2018.

Correction - I meant 1 October.  That is I will post my initial proposal
for the scope definition around this date.  The discussion of the scope
can be hashed out on the list.

> Not a lot of time till then, so here are my 2cents:
>
> First of all, I don't think the whole thing is worth it if the goal isn't
> to completely replace b2 as a top level build system.

I'm not addressing this now. I'll leave it for the scope discussion.
Everyone who want's to chime in will have their opportunity. So be
prepared to post again later.

>> I nominate myself (Robert Ramey) as review manager in this instance.
>
> You have my vote

LOL - so the current vote is 1 - 0
>
> Best
>
> Mike
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

CMake in Boost

Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> Sent: Thursday, September 27, 2018 8:36 PM
>
> On 9/27/18 11:23 AM, Mike Dev via Boost wrote:
> >> -----Original Message-----
> >> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
> >> c) Prior to this discussions can be held on the list regarding the scope
> >> of such an effort.  The review manager will distill these discussions to
> >> a statement of scope.  This will be posted around 30 October 2018.
>
> Correction - I meant 1 October.  That is I will post my initial proposal
> for the scope definition around this date.  The discussion of the scope
> can be hashed out on the list.


Ah ok, I understood your mail in such a way that you wanted to have the scope
discussion finished by then (31.10) and that you would then post the "result".
Sorry for chiming in prematurely.

Best

Mike




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: CMake in Boost

Boost - Dev mailing list
On 9/28/18 4:20 AM, Mike Dev via Boost wrote:

>> -----Original Message-----
>> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
>> Sent: Thursday, September 27, 2018 8:36 PM
>>
>> On 9/27/18 11:23 AM, Mike Dev via Boost wrote:
>>>> -----Original Message-----
>>>> From: Boost <[hidden email]> On Behalf Of Robert Ramey via Boost
>>>> c) Prior to this discussions can be held on the list regarding the scope
>>>> of such an effort.  The review manager will distill these discussions to
>>>> a statement of scope.  This will be posted around 30 October 2018.
>>
>> Correction - I meant 1 October.  That is I will post my initial proposal
>> for the scope definition around this date.  The discussion of the scope
>> can be hashed out on the list.
>
>
> Ah ok, I understood your mail in such a way that you wanted to have the scope
> discussion finished by then (31.10) and that you would then post the "result".
> Sorry for chiming in prematurely.

LOL _ I've just whacked out from giving my presentation at CPP con.

The original version is correct.  That is

Around 1 October I'll start out the scope discussion with an initial
proposal for the scope.  I expect this will reveal that there is a lot
of disagreement on this.  I the course of the next 30 days I'll gather
opinions and by 30 October hope to develop a boost style consensus.
That is a description which everyone can live with.  And call for
submissions.  I hope to have the review of the submissions start around
1 February 2019.

A reminder that this process will be a little different that the normal
one for libraries.  Traditionally, we've considered library submissions
one at at time for an accept/reject decision.  The problem here is that
the acceptance of one stops the process.  This is not a good match in
this case.  So we'll be considering the submissions simultaneously and
comparatively.  The general boost expectations will apply: that is,
functionality, testability, documentation, final determination in the
hands of the review manager.

FYI - I am now aware of three persons who are seriously considered
making such submissions.  Given the fact that we're giving lots of time
for persons to take their shot and that everyone is expert on build
systems, it wouldn't surprise me if there were more.

Sorry for the mixup.

Robert Ramey


>
> Best
>
> Mike
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost