Informal CMake meeting at CPPCon
Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey
Hi Robert, thanks for the update ! On 02.10.2017 12:04, Robert Ramey via Boost wrote:
Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject.
Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese
This was a small but I think a representative group. After some preliminary back and forth, I think we agreed:
a) Nothing was going change regarding the current build system until there was a real alternative in place.
b) That we should support serious proposals to implement CMake support within boost.
c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice.
d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process.
e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take.
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist, by modularizing the build infrastructure such that some libraries might switch to CMake while others might continue using Boost.Build ? I continue to believe that there is no real alternative to such an approach, as you can't coerce anyone into migrating to a new tool, you can only offer a new tool and hope that people will (eventually) migrate. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist...
David Sankel made it pretty clear that in the "final solution", CMake will be mandatory and Boost.Build will be optional. Unless I misunderstood (David, feel free to correct me).
On 02.10.2017 12:22, Vinnie Falco via Boost wrote:
On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist... David Sankel made it pretty clear that in the "final solution", CMake will be mandatory and Boost.Build will be optional. Unless I misunderstood (David, feel free to correct me).
Good luck convincing the whole community to adopt that. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Boost - Dev mailing list wrote
On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost <
boost@.boost
> wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist...
David Sankel made it pretty clear that in the "final solution", CMake will be mandatory and Boost.Build will be optional. Unless I misunderstood (David, feel free to correct me).
I don't remember anyone making that statement. Louis -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
On 10/3/17 8:18 AM, Louis Dionne via Boost wrote:
Boost - Dev mailing list wrote
On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost <
boost@.boost
> wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist...
David Sankel made it pretty clear that in the "final solution", CMake will be mandatory and Boost.Build will be optional. Unless I misunderstood (David, feel free to correct me).
I don't remember anyone making that statement.
Hmmm - I do remember getting that impression though it may not have been explicitly stated. My reaction was to point out that we didn't have to address this issue until we actually had a real CMake alternative for Boost. I think this got us over the hump to where could find some common ground on something that would move us forward. Of course I don't remember every word and detail now. But I believe that my original summary captures the essential sense of the mercifully short and in my view productive meeting. Robert Ramey.
On Tue, Oct 3, 2017 at 11:27 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/3/17 8:18 AM, Louis Dionne via Boost wrote:
Boost - Dev mailing list wrote
On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost <
boost@.boost
> wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist...
David Sankel made it pretty clear that in the "final solution", CMake will be mandatory and Boost.Build will be optional. Unless I misunderstood (David, feel free to correct me).
I don't remember anyone making that statement.
Hmmm - I do remember getting that impression though it may not have been explicitly stated. My reaction was to point out that we didn't have to address this issue until we actually had a real CMake alternative for Boost. I think this got us over the hump to where could find some common ground on something that would move us forward. Of course I don't remember every word and detail now. But I believe that my original summary captures the essential sense of the mercifully short and in my view productive meeting.
I want to revive this old thread, because I think it's extremely important. I've been using CMake since around 2007 and I'm extremely familiar with it. If the Boost developers plan to support CMake or have an ongoing repository with CMake scripts they're working on, please share it with me as I'd love to pitch in. Having said that, I want to be frank. I apologize in advance if this offends anyone. My goal is to not offend anyone's efforts, I just want to be brutally honest for a moment. Boost Build is an abomination of a build system. It's a complex and niche system designed (from my perspective; not sure what the real intent was) just to build boost. It has an extremely steep learning curve and even the most basic build instructions are incredibly complex. Forget cross compiling. Why should I have to define a user-config.jam that specifies over 20 compiler arguments? If you've never tried to build boost for Android, then forget doing it with bjam. First, try doing a google search to see how others have solved the problem. You will literally never see the same solution twice. Furthermore, instructions you find are very dependent on the specific version of NDK and Boost combination used for those instructions. You could spend days going through dozens of solutions but never find one that works. The point of all my venting is that bjam is not sustainable as a public facing build system for Boost. I get that the boost devs are probably already very familiar with it and that makes them comfortable with it. But the users and builders of the Boost library struggle with it constantly. It's not something I have used in my 15+ year career as a software engineer outside of building boost, which I do not do very often. So there's no incentive for me to learn it and become familiar with it beyond the "means to an end" task of getting the libraries I have dependencies on. I've been using a set of comprehensive CMake scripts to build boost here: https://github.com/Orphis/boost-cmake It makes it very easy to build boost consistently across multiple platforms, including cross compiling to Android NDK. Furthermore, the NDK already provides a CMake toolchain file to make the task of building libraries for Android a trivial matter. This project is far from perfect, as it's difficult to add support for building new versions of boost. But I think it's a good start if the boost developers do not have something they're working on already. I've been working with the author to add proper install target support. I've used it and it works great. So it's come a long way and I recommend everyone take a look at it. Lastly I want to just say that supporting multiple build systems simply because a portion of the community is adverse to using CMake is going to be extremely counterproductive. What you'll end up with is the bjam developers not updating CMake, and the CMake developers not updating the bjam build scripts. Happens every where I have worked that has more than one build system in place. I really do not recommend this approach. While more controversial, I recommend that those that currently prefer bjam just make the switch to CMake as long as it fulfills all the requirements. Having people's personal preferences get in the way will just create unnecessary complexity. Just thinking of this objectively. Again I apologize for the frustration that's obviously leaking through my email here. I love boost but for years I've dealt with the frustration of having to build it. It should be a simple matter, but like a some things in boost, the current build system is too overengineered.
On 1/12/18 7:38 AM, Robert Dailey via Boost wrote:
I want to revive this old thread, because I think it's extremely important. I've been using CMake since around 2007 and I'm extremely familiar with it. If the Boost developers plan to support CMake or have an ongoing repository with CMake scripts they're working on, please share it with me as I'd love to pitch in.
<snip> This should probably be on a different thread. My intention of this meeting was to promote the idea that proposals for boost tools - specifically Boost support for CMake - be subjected to the Boost Review process. It is my view that the review system has been the the fundamental reason that Boost has been more successful than others in producing and distributing C++ libraries. I believe that this idea was accepted by consensus of those present. It's my hope that extending this system to cover Boost tools will. a) promote the creation/maintenance of tools which are easier to use, better documented and regularly tested before being applied to boost infrastructure. b) diminish contentiousness among boost members by getting agreement on issues before tools are implemented. c) make it easier for interested parties to contribute fixes, enhancements. So far, one proposal for incorporation of CMake into boost infrasture has been submitted and endorsed for review. The author is Paul Fultz. You can find it in git hub. It hasn't been up for formal review yet, but there is no reason why anyone can't review/comment on it now. There is also no reason why someone cannot submit an alternate proposal - in fact that might be interesting. Not that any such submissions should include what we require for all boost submissions: Documentation, Tests, Boost License and of course code. Robert Ramey
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Dailey via Boost Sent: 12 January 2018 15:39 To: Boost Developers Cc: Robert Dailey; Robert Ramey Subject: Re: [boost] [SPAM] Re: Informal CMake meeting at CPPCon
On Tue, Oct 3, 2017 at 11:27 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/3/17 8:18 AM, Louis Dionne via Boost wrote:
Boost - Dev mailing list wrote
On Mon, Oct 2, 2017 at 9:16 AM, Stefan Seefeld via Boost <
boost@.boost
> wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist...
David Sankel made it pretty clear that in the "final solution", CMake will be mandatory and Boost.Build will be optional. Unless I misunderstood (David, feel free to correct me).
I don't remember anyone making that statement.
Hmmm - I do remember getting that impression though it may not have been explicitly stated. My reaction was to point out that we didn't have to address this issue until we actually had a real CMake alternative for Boost. I think this got us over the hump to where could find some common ground on something that would move us forward. Of course I don't remember every word and detail now. But I believe that my original summary captures the essential sense of the mercifully short and in my view productive meeting.
I want to revive this old thread, because I think it's extremely important. I've been using CMake since around 2007 and I'm extremely familiar with it. If the Boost developers plan to support CMake or have an ongoing repository with CMake scripts they're working on, please share it with me as I'd love to pitch in.
Having said that, I want to be frank. I apologize in advance if this offends anyone. My goal is to not offend anyone's efforts, I just want to be brutally honest for a moment.
Boost Build is an abomination of a build system. It's a complex and niche system designed (from my perspective; not sure what the real intent was) just to build boost. It has an extremely steep learning curve and even the most basic build instructions are incredibly complex. Forget cross compiling. Why should I have to define a user-config.jam that specifies over 20 compiler arguments? If you've never tried to build boost for Android, then forget doing it with bjam. First, try doing a google search to see how others have solved the problem. You will literally never see the same solution twice. Furthermore, instructions you find are very dependent on the specific version of NDK and Boost combination used for those instructions. You could spend days going through dozens of solutions but never find one that works.
The point of all my venting is that bjam is not sustainable as a public facing build system for Boost. I get that the boost devs are probably already very familiar with it and that makes them comfortable with it. But the users and builders of the Boost library struggle with it constantly. It's not something I have used in my 15+ year career as a software engineer outside of building boost, which I do not do very often. So there's no incentive for me to learn it and become familiar with it beyond the "means to an end" task of getting the libraries I have dependencies on.
I've been using a set of comprehensive CMake scripts to build boost here: https://github.com/Orphis/boost-cmake
It makes it very easy to build boost consistently across multiple platforms, including cross compiling to Android NDK. Furthermore, the NDK already provides a CMake toolchain file to make the task of building libraries for Android a trivial matter. This project is far from perfect, as it's difficult to add support for building new versions of boost. But I think it's a good start if the boost developers do not have something they're working on already. I've been working with the author to add proper install target support. I've used it and it works great. So it's come a long way and I recommend everyone take a look at it.
Lastly I want to just say that supporting multiple build systems simply because a portion of the community is adverse to using CMake is going to be extremely counterproductive. What you'll end up with is the bjam developers not updating CMake, and the CMake developers not updating the bjam build scripts. Happens every where I have worked that has more than one build system in place. I really do not recommend this approach. While more controversial, I recommend that those that currently prefer bjam just make the switch to CMake as long as it fulfills all the requirements. Having people's personal preferences get in the way will just create unnecessary complexity. Just thinking of this objectively.
Again I apologize for the frustration that's obviously leaking through my email here. I love boost but for years I've dealt with the frustration of having to build it. It should be a simple matter, but like a some things in boost, the current build system is too overengineered.
I hear your frustration (though I find that bjam works fine for me, and does some things that CMake can't). But, by itself, knocking bjam won't help). There is a clear declared wish and willingness to make CMake work for building Boost. Someone needs to make CMake 'just work' for people (including explaining how - it's all greek to me ;-) ). (And it isn't going to be the people who have worked over many years supporting bjam - it is all they can do to keep bjam running). It's no good trying to stop support for bjam unless CMake is really working well; I don't get the impression that it really is working yet :-( It is lack of CMake enthusiasts input is the missing thing here. So yes, please, help make it happen. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 10/2/17 9:16 AM, Stefan Seefeld via Boost wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist, by modularizing the build infrastructure such that some libraries might switch to CMake while others might continue using Boost.Build ? I continue to believe that there is no real alternative to such an approach, as you can't coerce anyone into migrating to a new tool, you can only offer a new tool and hope that people will (eventually) migrate.
That happens to be my position as well - see my presentation boost 2.0 from a couple of years ago. But it's pretty clear that that's a minority opinion. It's also clear that there is no point in doing much of anything until we have clear idea how CMake is to be used in the context of boost. I'm looking for something that we can agree on so some progress can be made. I'm please that reached a concensus that proposed tools should go through a review process similar to that of libraries. I think this will be a positive step in helping boost move forward. Robert Ramey
On 02.10.2017 13:06, Robert Ramey via Boost wrote:
On 10/2/17 9:16 AM, Stefan Seefeld via Boost wrote:
Have you discussed the possibility for the two (Boost.Build and CMake) to coexist, by modularizing the build infrastructure such that some libraries might switch to CMake while others might continue using Boost.Build ? I continue to believe that there is no real alternative to such an approach, as you can't coerce anyone into migrating to a new tool, you can only offer a new tool and hope that people will (eventually) migrate.
That happens to be my position as well - see my presentation boost 2.0 from a couple of years ago. But it's pretty clear that that's a minority opinion. It's also clear that there is no point in doing much of anything until we have clear idea how CMake is to be used in the context of boost.
I'm looking for something that we can agree on so some progress can be made. I'm please that reached a concensus that proposed tools should go through a review process similar to that of libraries. I think this will be a positive step in helping boost move forward.
It is indeed. Thanks to you all to try to resolve this problem. Stefan -- ...ich hab' noch einen Koffer in Berlin...
c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice.
There is good reason why tooling doesn't go through a formal review process, it could never pass a formal review. I think requiring a cmake conversion to pass a formal review is an impossible ask. The cmake conversion will never reach the quality of the Boost.Build one in any reasonable time period, and moreover, everything keeps shifting with time. I'd support a simple majority, yay or nay vote for the proposed cmake design. Without commentary or review. Makes things feasible. And a second simple majority yay or nay for when Boost.Build is to be turned off (if ever). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 02.10.2017 14:20, Niall Douglas via Boost wrote:
c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. There is good reason why tooling doesn't go through a formal review process, it could never pass a formal review.
I think that depends on the goal (and metric) of such a review.
I think requiring a cmake conversion to pass a formal review is an impossible ask. The cmake conversion will never reach the quality of the Boost.Build one in any reasonable time period, and moreover, everything keeps shifting with time.
True enough.
I'd support a simple majority, yay or nay vote for the proposed cmake design. Without commentary or review. Makes things feasible. And a second simple majority yay or nay for when Boost.Build is to be turned off (if ever).
I believe you are reaching the wrong conclusions from the above: It's not because a community as big and heterogeneous as Boost can not agree on whether to switch to CMake or to stay with Boost.Build that anyone has the right (or simply the power !) to coerce everyone into accepting a decision made by a few nonetheless. It's simply that the goal is ill-conceived. This is Open Source; it is powered by the people who contribute to and maintain all the projects. You can cheer-lead infrastructure efforts all you want, you do have to accept the decision of those who do the work. (And to be very clear, let me repeat: by "work" I'm not merely referring to the work of migrating, but that of maintaining and simply using the infrastructure day-to-day.) Any effort to help improve our (developers' and maintainers') workflow is *highly* appreciated. But as soon as it's a hindrance rather than help, I have to say: please get out of the way. So, to end on a positive note: I appreciate Robert's mail as it conveys a sense of trying to find consensus. I hope we can build on top of that. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 10/2/17 11:20 AM, Niall Douglas via Boost wrote:
c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice.
There is good reason why tooling doesn't go through a formal review process, it could never pass a formal review.
I don't think anyone can know that.
I think requiring a cmake conversion to pass a formal review is an impossible ask.
Doesn't seem impossible to me.
he cmake conversion will never reach the quality of the Boost.Build
I think that we're here because many believe that CMake has always been a better alternative than boost build.
one in any reasonable time period, and moreover, everything keeps shifting with time.
everthing always shifts with time.
I'd support a simple majority, yay or nay vote for the proposed cmake design. Without commentary or review. Makes things feasible. And a second simple majority yay or nay for when Boost.Build is to be turned off (if ever).
Hmmm - the boost review process is certainly nothing like a simple yay/nay vote. This is exactly the reason that the boost librarys are considered among the best. Also, there has not been actually been any cmake design submitted. Paul has indicated that he believes that it is unnecessary to do this. So under these conditions, no boost-like review could be conducted. So we are again at a stand still. It's a golden opportunity for anyone who want's to submit their own proposal for usage of CMake in Boost. Robert Ramey
On Mon, 2017-10-02 at 20:31 -0700, Robert Ramey via Boost wrote:
On 10/2/17 11:20 AM, Niall Douglas via Boost wrote:
c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice.
There is good reason why tooling doesn't go through a formal review process, it could never pass a formal review.
I don't think anyone can know that.
I think requiring a cmake conversion to pass a formal review is an impossible ask.
Doesn't seem impossible to me.
he cmake conversion will never reach the quality of the Boost.Build
I think that we're here because many believe that CMake has always been a better alternative than boost build.
one in any reasonable time period, and moreover, everything keeps shifting with time.
everthing always shifts with time.
I'd support a simple majority, yay or nay vote for the proposed cmake design. Without commentary or review. Makes things feasible. And a second simple majority yay or nay for when Boost.Build is to be turned off (if ever).
Hmmm - the boost review process is certainly nothing like a simple yay/nay vote. This is exactly the reason that the boost librarys are considered among the best.
Also, there has not been actually been any cmake design submitted. Paul has indicated that he believes that it is unnecessary to do this. So under these conditions, no boost-like review could be conducted. So we are again at a stand still.
No that is not what I am saying at all. The BCM which is like a "library" for cmake will go through a formal review process. Then after its accepted the cmake build files using BCM will go through an "open" review process and then merged into boost. .
On 10/2/2017 12:04 PM, Robert Ramey via Boost wrote:
Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject.
Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese
This was a small but I think a representative group. After some preliminary back and forth, I think we agreed:
a) Nothing was going change regarding the current build system until there was a real alternative in place.
b) That we should support serious proposals to implement CMake support within boost.
c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice.
d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process.
e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take.
I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way.
My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some.
Robert Ramey
Paul Fultz's work to convert Boost Build jam files to CMake CMakeLists.txt files should be valued highly, as well as his bcm CMake modules. It is still missing some features, of which the most prominent I noticed is lack of support for Boost Build conditional requirements, but it is certainly a worthy undertaking. It is possible that no parsing can flawlessly convert Boost Build jamfiles to CMakeLists.txt files, but the effort is certainly worth the results.
Boost - Dev mailing list wrote
[...]
My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some.
Robert Ramey
Thank you Robert for the update to the mailing list! I think this makes perfect sense and I support what you've outlined. More specifically, here's how I see things: BCM (and any other competing proposal) should go through a formal review. If we agree that BCM is the right way to support CMake in Boost, it can be accepted as a "library" (although a CMake library) as a result of the formal review process. It will then be up to the community to start writing their CMakeLists.txt files, using BCM for convenience and to enforce coherency amongst the Boost libraries. That being said, my understanding is that Paul has already done a lot of work in that direction, and it would be wise to reuse it. I do think, however, that the actual CMakeLists.txt in each Boost library is a completely different matter than BCM, which is the library that will be put up for review. Louis -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
participants (9)
-
Edward Diener -
Louis Dionne -
Niall Douglas -
paul -
Paul A. Bristow -
Robert Dailey -
Robert Ramey -
Stefan Seefeld -
Vinnie Falco