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
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...
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
-----Original Message----- From: Boost
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
On 9/15/18 3:25 AM, mike via Boost wrote:
-----Original Message----- From: Boost
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
-----Original Message----- From: Boost
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
On 9/27/18 11:23 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost
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
-----Original Message----- From: Boost
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
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
On 9/28/18 4:20 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost
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
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
participants (4)
-
Mike Dev
-
mike.dev@gmx.de
-
Robert Ramey
-
Stefan Seefeld