Switch to CMake -- Analysis
Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
[...] our build system has become an impediment for many developers and users, existing and prospective.
Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas
On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
Hi list,
After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit?
Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such.
Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
[...] our build system has become an impediment for many developers and users, existing and prospective.
Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit.
Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors.
Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;)
All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config).
pkg-config is build-indenpendent so can be consumed by meson and bazel.
Am 21.07.2017 4:55 nachm. schrieb "paul" <pfultz2@yahoo.com>: On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config).
pkg-config is build-indenpendent so can be consumed by meson and bazel. It's also consumable by cmake. Doesn't propagate build properties though. Only plain and simple strings on how to invoke the compiler/linker. Anything else is not the default behavior.
On 07/21/17 18:00, Thomas Heller via Boost wrote:
Am 21.07.2017 4:55 nachm. schrieb "paul" <pfultz2@yahoo.com>:
On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config).
pkg-config is build-indenpendent so can be consumed by meson and bazel.
It's also consumable by cmake. Doesn't propagate build properties though. Only plain and simple strings on how to invoke the compiler/linker. Anything else is not the default behavior.
It does, at least with regard to macros to define, include/library directories to add and libraries to link with. Or do you have different properties in mind?
Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" < boost@lists.boost.org>: On 07/21/17 18:00, Thomas Heller via Boost wrote:
Am 21.07.2017 4:55 nachm. schrieb "paul" <pfultz2@yahoo.com>:
On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config).
pkg-config is build-indenpendent so can be consumed by meson and bazel.
It's also consumable by cmake. Doesn't propagate build properties though. Only plain and simple strings on how to invoke the compiler/linker. Anything else is not the default behavior.
It does, at least with regard to macros to define, include/library directories to add and libraries to link with. Or do you have different properties in mind? Well, recently, cmake got support for c++ feature properties for example. The big advantage is that the flags carry on semantics and the build system is able to determine conflicts etc. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
On Fri, 2017-07-21 at 17:39 +0200, Thomas Heller via Boost wrote:
Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" < boost@lists.boost.org>:
On 07/21/17 18:00, Thomas Heller via Boost wrote:
Am 21.07.2017 4:55 nachm. schrieb "paul" <pfultz2@yahoo.com>:
On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config).
pkg-config is build-indenpendent so can be consumed by meson and bazel.
It's also consumable by cmake. Doesn't propagate build properties though. Only plain and simple strings on how to invoke the compiler/linker. Anything else is not the default behavior.
It does, at least with regard to macros to define, include/library directories to add and libraries to link with. Or do you have different properties in mind?
Well, recently, cmake got support for c++ feature properties for example. The big advantage is that the flags carry on semantics and the build system is able to determine conflicts etc.
Well I think you can encode those using pkg-config files. You can use the `replaces` and `conflicts` fields to help pkg-config resolve the flag. The C++ features properties still lack maturity with cmake.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo st
On 22/07/2017 03:00, Thomas Heller wrote:
It's also consumable by cmake. Doesn't propagate build properties though. Only plain and simple strings on how to invoke the compiler/linker. Anything else is not the default behavior.
pkg-config can propagate whatever arbitrary string variables you like, though obviously the caller then has to know to ask for them (you can get a list of all defined variables, though).
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Heller via Boost Sent: Freitag, 21. Juli 2017 16:21 To: boost@lists.boost.org Cc: Thomas Heller <thom.heller@gmail.com> Subject: [boost] Switch to CMake -- Analysis ... Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit.
+1 I like this approach very much! Just to check if I understand correctly: When you write "CMake Module, which invokes b2 instead of the compiler directly", do you mean a CMake Module which would also be able to generate the Jamfile, or would all Boost library authors/maintainers still have to manually write the Jamfile? Because if you meant the latter, do you think that the former would be possible?
Am 21.07.2017 5:15 nachm. schrieb "Groke, Paul via Boost" < boost@lists.boost.org>:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Heller via Boost Sent: Freitag, 21. Juli 2017 16:21 To: boost@lists.boost.org Cc: Thomas Heller <thom.heller@gmail.com> Subject: [boost] Switch to CMake -- Analysis ... Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit.
+1 I like this approach very much! Just to check if I understand correctly: When you write "CMake Module, which invokes b2 instead of the compiler directly", do you mean a CMake Module which would also be able to generate the Jamfile, or would all Boost library authors/maintainers still have to manually write the Jamfile? Because if you meant the latter, do you think that the former would be possible? I mean the latter. Using the existing jamfiles. I don't see value in replacing the already existing ones with auto generated so I haven't thought about it. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 21.07.2017 10:21, Thomas Heller via Boost wrote:
Hi list,
After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake.
Mostly, yes. And in addition, people are very polarized (even more so as a result of this ongoing discussion). So to frame the question as "should we stay with Boost.Build or should we move to CMake" is extremely counter-productive. We need a way to continue to draw from the wealth of expertise encoded in the existing Boost.Build infrastructure as well as the community around it, while at the same time being open to change (in general, not just towards alternative build tools). To invoke a higher authority to decide to get out of this stalemate is foolish, as it entirely ignores both how Open Source works in general (you can't coerce people into doing things they aren't motivated to do to begin with), as well as the real reason for the stalemate: it's due to an artificial dichotomy: either Boost.Build or CMake, globally, for everyone at once. Here is (once again) how I would approach this instead: * Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals). * Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic. * With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities. Does this process appeal to anyone ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
Does this process appeal to anyone ?
It sounds reasonable in theory, but I think the first thing that should be addressed is the use-case where Users of Boost who have pre-built binaries are able to easily consume Boost in their projects with support from within Boost itself and not the FindBoost.cmake that comes with CMake which is perpetually behind the latest Boost version. I'm talking about this: CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message): Imported targets not available for Boost version Call Stack (most recent call first): cmake/share/cmake-3.8/Modules/FindBoost.cmake:866 (_Boost_COMPONENT_DEPENDENCIES) cmake/share/cmake-3.8/Modules/FindBoost.cmake:1457 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:67 (find_package) <https://travis-ci.org/vinniefalco/Beast/jobs/255894286#L1385> Fixing this seems entirely non-controversial. It doesn't displace Boost.Build, it adds something that users clearly want (for example, I want this myself), it enhances the value of Boost and it does so in a non-intrusive way. And some work has already been done on this...if the Steering Committee is going make proclamations why don't they start with this instead of turning members of the Boost developer community against each other? Thanks
On 21.07.2017 12:03, Vinnie Falco via Boost wrote:
Does this process appeal to anyone ? It sounds reasonable in theory, but I think the first thing that should be addressed is the use-case where Users of Boost who have
On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote: pre-built binaries are able to easily consume Boost in their projects with support from within Boost itself and not the FindBoost.cmake that comes with CMake which is perpetually behind the latest Boost version.
You are talking about a use-case involving a Boost *binary* package. How is this related to how Boost is built, i.e. how such binaries are produced ? It seems to me that to provide a tool that can discover compiler flags needed to build with an existing Boost *binary* installation is quite trivial to come up with, even if this requires some additional metadata to be added to Boost installations. (The really hard use-case, which I'd prefer to dismiss as impossible, is to enable users to "consume" Boost *sources*, i.e. to integrate a Boost build into a user's build process. While I'm not opposed to such an idea, I don't want to have to support it explicitly.) Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, Jul 21, 2017 at 9:15 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
You are talking about a use-case involving a Boost *binary* package. How is this related to how Boost is built, i.e. how such binaries are produced ?
It is not related to building Boost but it solves something that annoys a non-zero percentage of Boost users who use CMake. Its not "moving the build system to cmake" but its step forward.
On 21.07.2017 12:19, Vinnie Falco via Boost wrote:
On Fri, Jul 21, 2017 at 9:15 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
You are talking about a use-case involving a Boost *binary* package. How is this related to how Boost is built, i.e. how such binaries are produced ? It is not related to building Boost but it solves something that annoys a non-zero percentage of Boost users who use CMake.
Then *please* let's not add unrelated points to the discussion, for the sake of getting a handle of what problems we have to solve, and how. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost <boost@lists.boost.org> wrote:
Then *please* let's not add unrelated points to the discussion, for the sake of getting a handle of what problems we have to solve, and how.
Hmm...my apologies but I think this error is very much on-topic:
CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message): Imported targets not available for Boost version
On 07/21/17 18:57, Stefan Seefeld via Boost wrote:
Here is (once again) how I would approach this instead:
* Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals). * Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic. * With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities.
Does this process appeal to anyone ?
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used. Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
On 07/21/17 18:57, Stefan Seefeld via Boost wrote:
Here is (once again) how I would approach this instead:
* Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals). * Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic. * With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities.
Does this process appeal to anyone ?
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch. Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later). I'm merely pointing out that rather then switching from Boost.Build to CMake atomically, we should attempt to do this piece-wise (and allow projects to keep the current logic if they prefer), which means supporting *two* build systems, not "a dozen". I'm really trying hard to come up with *practical* proposals to get out of the current stalemate. But replies like the above don't help at all.
Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.
So you think we can't transition one library at a time, but you believe it will be possible to do a switch for 100+ libraries synchronously ? Sorry, but I can't follow your reasoning... Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.
So you think we can't transition one library at a time, but you believe it will be possible to do a switch for 100+ libraries synchronously ? Sorry, but I can't follow your reasoning...
I wasn't referring to the transition process but rather the resulting model adopted by Boost. If that model includes multiple build systems then it is bound to have problems stemming from the integration. Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job. A step by step switch adds a period (potentially, open-ended) when people have to maintain both build systems. As a Boost developer, I'm not happy about that. As a user, I might not be happy either, if one of the build systems doesn't actually work in a Boost release. Regarding CMake as a candidate build system, I'm not convinced that the switch would benefit Boost in terms of "new blood" or something. I don't think the build system is something that is keeping millions of developers out there from contributing to Boost, as being advertised. It might be one, though probably not the major point, but I don't think anything will change e.g. wrt. maintenance if we switch right now. Most of the work doesn't even touch the build system or comes down to copying and pasting a piece of jamfile. I recognize that CMake has gained popularity and it is easier to find support for it online. But I know that more than once I've been puzzled about how to do one thing or the other in it, much like with Boost.Build. So as a Boost developer, there may be a slight plus on CMake side for me, but absolutely not worth the damage that has been inflicted on Boost already on the road to it. As a Boost user I really don't care as I never ever integrate third party projects into my project build system as I consider that a broken approach in the first place.
On 07/21/17 20:10, Andrey Semashev wrote:
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.
So you think we can't transition one library at a time, but you believe it will be possible to do a switch for 100+ libraries synchronously ? Sorry, but I can't follow your reasoning...
I wasn't referring to the transition process but rather the resulting model adopted by Boost. If that model includes multiple build systems then it is bound to have problems stemming from the integration.
Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job. A step by step switch adds a period (potentially, open-ended) when people have to maintain both build systems. As a Boost developer, I'm not happy about that. As a user, I might not be happy either, if one of the build systems doesn't actually work in a Boost release.
Regarding CMake as a candidate build system, I'm not convinced that the switch would benefit Boost in terms of "new blood" or something. I don't think the build system is something that is keeping millions of developers out there from contributing to Boost, as being advertised. It might be one, though probably not the major point, but I don't think anything will change e.g. wrt. maintenance if we switch right now. Most of the work doesn't even touch the build system or comes down to copying and pasting a piece of jamfile.
I recognize that CMake has gained popularity and it is easier to find support for it online. But I know that more than once I've been puzzled about how to do one thing or the other in it, much like with Boost.Build. So as a Boost developer, there may be a slight plus on CMake side for me, but absolutely not worth the damage that has been inflicted on Boost already on the road to it. As a Boost user I really don't care as I never ever integrate third party projects into my project build system as I consider that a broken approach in the first place.
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
You'll also need whatever version of the *actual* build system CMake is generating for. So, we go from having 0 dependencies to at least 2: CMake itself, and the target build system. -- chris
On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost <boost@lists.boost.org> wrote:
On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost < boost@lists.boost.org> wrote:
You'll also need whatever version of the *actual* build system CMake is generating for. So, we go from having 0 dependencies to at least 2: CMake itself, and the target build system.
-- chris
I think this exactly summarizes both advantage and Achilles heel of Boost.Build and the entire vision of Boost Community. ------------------------------------------------------------------------ Boost.Build is ok for 100% self contained library that needs nothing but itself and boost. This why declarative approach of BB actually works not bad and you can run from single line build of multiple variants. However the REAL WORLD isn't that "perfect". In real world scenarios boost libraries require complex configuration and depend on 3rd part libraries. This requires complex configuration - search for libraries, headers running some checks. This makes BB declarative/tags approach programming nightmare. As the author of Boost.Locale library that has complex dependencies and build options I can say it is impossible to maintain complex projects with BB. Why: 1. Support of basic features given by any normal REAL WORLD build system barely exists (library search configuration options etc) 2. Documentation isn't good and it was this for years. 3. Knowledge exits only for few people. Do you want a proof? Please find me a tutorial how to search a 3rd part library or complete reference documentation for that. I mean: (a) find if library exists (with optional search path) (b) find if headers exists (with optional search path) (c) given this turn on and off some feature of fail library build (d) propagate results to tests. And this is one of the most basic and trivial feature that exists in every real world build system. And now take a look on this code: https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L... Lines 124-145 this is how I search ICU for Boost.Locale And this is how it is done in BB: https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2#L63 Lines 63-190 I look at the code and I can barely understand what is written. Options that are in use aren't documented. And only very few people on this list can describe me what is going on. So please all of you complaining how Boost.Build is great in comparisons to cmake and what cmake can't do. I want you to tell what BB can't do? It can't support complex projects that aren't self contained properly. I want also relate to another issue that was pointed there? That CMake can't run ./b2 toolset=msvc-12,msvc-14,mingw Boost.Build can't either once a 3rd part library required as search paths for each need to be different. What about running? ./b2 -sICU_PATH=/opt/icu56 .. ./b2 -sICU_PATH=/opt/icu59 .. And this is one of the principle issues of BB - its declarative way of providing configuration. --------- So I'm really thrilled by moving to CMake, not because it is perfect build system - it isn't. But at least it (a) feature rich (b) well documented (c) it works for many cases BB would required custom build macros So instead of trying to live in pure world without dependencies please consider thous who can't afford it. Artyom Beilis
On 21/07/17 20:53, Artyom Beilis via Boost wrote: [...]
And this is one of the most basic and trivial feature that exists in every real world build system.
And now take a look on this code:
https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L...
Lines 124-145 this is how I search ICU for Boost.Locale
Note that you can further simplify this to a single line: find_package(ICU COMPONENTS uc data i18n) and then use the imported targets ICU::uc, ICU::data and ICU::i18n to link with. Handles all the debug postfixes, alternative library names on Windows (dt/data, in/i18n) etc. It's basically what you're doing, but a bit more comprehensive and flexible (by using the imported targets, you allow for /export/ of the target configuration for use by end users and downstream components). This requires FindICU.cmake, which is provided in newer CMake releases. But it's absolutely possible to copy this into your own project to support older CMake releases (I do this myself). See https://cmake.org/cmake/help/v3.9/module/FindICU.html for further details. Regards, Roger
On Fri, Jul 21, 2017 at 11:14 PM, Roger Leigh via Boost <boost@lists.boost.org> wrote:
On 21/07/17 20:53, Artyom Beilis via Boost wrote: [...]
And this is one of the most basic and trivial feature that exists in every real world build system.
And now take a look on this code:
https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L...
Lines 124-145 this is how I search ICU for Boost.Locale
Note that you can further simplify this to a single line:
find_package(ICU COMPONENTS uc data i18n)
and then use the imported targets ICU::uc, ICU::data and ICU::i18n to link with. Handles all the debug postfixes, alternative library names on Windows (dt/data, in/i18n) etc. [snip] This requires FindICU.cmake, which is provided in newer CMake releases. But it's absolutely possible to copy this into your own project to support older CMake releases (I do this myself). See https://cmake.org/cmake/help/v3.9/module/FindICU.html for further details.
Regards, Roger
You are 100% right except this code dates to days when CMake was about 2.6/2.8. But indeed it can be updated. Artyom
On 21/07/2017 22:14, Roger Leigh via Boost wrote:
On 21/07/17 20:53, Artyom Beilis via Boost wrote: [...]
And this is one of the most basic and trivial feature that exists in every real world build system.
And now take a look on this code:
https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L...
Lines 124-145 this is how I search ICU for Boost.Locale
Note that you can further simplify this to a single line:
find_package(ICU COMPONENTS uc data i18n)
and then use the imported targets ICU::uc, ICU::data and ICU::i18n to link with. Handles all the debug postfixes, alternative library names on Windows (dt/data, in/i18n) etc. It's basically what you're doing, but a bit more comprehensive and flexible (by using the imported targets, you allow for /export/ of the target configuration for use by end users and downstream components).
The old form also allows finding the various ICU libraries from different installations / versions. The COMPONENTS approach doesn't have that issue.
This requires FindICU.cmake, which is provided in newer CMake releases. But it's absolutely possible to copy this into your own project to support older CMake releases (I do this myself). See https://cmake.org/cmake/help/v3.9/module/FindICU.html for further details.
Regards, Roger
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 21 July 2017 at 21:53, Artyom Beilis via Boost <boost@lists.boost.org> wrote:
On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost <boost@lists.boost.org> wrote:
On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost < boost@lists.boost.org> wrote:
You'll also need whatever version of the *actual* build system CMake is generating for. So, we go from having 0 dependencies to at least 2: CMake itself, and the target build system.
-- chris
I think this exactly summarizes both advantage and Achilles heel of Boost.Build and the entire vision of Boost Community. ------------------------------------------------------------------------
[...] As the author of Boost.Locale library that has complex dependencies and build options I can say it is impossible to maintain complex projects with BB.
Why:
1. Support of basic features given by any normal REAL WORLD build system barely exists (library search configuration options etc) 2. Documentation isn't good and it was this for years. 3. Knowledge exits only for few people.
Do you want a proof? Please find me a tutorial how to search a 3rd part library or complete reference documentation for that.
I'd like to second Artyom's comments here. Boost.GIL may serve as another example - with I/O API depending on number of external libraries to support raster formats. Back in 2010, during and long after the GIL review, I remember Christian Henning (author and maintainer of GIL) and myself, we were having hard times over long months trying to complete the Boost.Build setup for the library. I don't remember if eventually Christian released GIL with user friendly support for third-party libraries. I'd been trying to convince myself [1] to like Boost.Build Extensions [2] for some time. For several years after, I'd be lurking around the numerous Boost.GIL bugs on the Trac trying convince myself to pick and work on some, but the Boost.Build adventure was putting me off, effectively. Eventually, I gave up looking at GIL completely. I was involved in Boost.Geometry for quite some time, especially during period following the review. Since Boost.Geometry does not require any dependencies Boost.Build configuration was pretty straightforward. Not for examples [4] and (some) tests though. For those, it turned to easier to maintain copy of third-party libraries in-source [5]. Boost.GIL adventure repeated. In my experience, Boost.Build works great to build...self-contained Boost. For an ad-hoc/supporting contributor to Boost, Boost.Build often proved to be hurdle hard to get over. I think that may be the case for many developers who have free slot of time on a Sunday afternoon and want to pick and shoot a bug in a library. Lucky one, if the library is external dependencies-free. To defend my position as willing and not as biased against Boost.Build as it may seem, a while ago I developed Boost.Build plug-in [6] for Qt Creator. OTOH, I have love-n-hate view on CMake, but I can at least a) transit knowledge between projects b) configure build via command line c) browse huge number of CMake-ified projects on GitHub to learn about good CMake configurations (CMake docs is a syntax/commands _reference_, but it is Shit in terms of presenting idiomatic and complex configurations, best practices, do's and don'ts, and often outdated Wiki does not help either) [1] http://mateusz.loskot.net/post/2010/10/17/notes-on-boost-build-for-boost-gil... [2] https://svn.boost.org/svn/boost/sandbox/tools/build_extensions/ [3] https://github.com/mloskot/boost-gil-workshop/tree/gil-io2-gdal [4] https://github.com/boostorg/geometry/tree/develop/example/with_external_libs [5] https://github.com/boostorg/geometry/tree/develop/example/with_external_libs... [6] https://github.com/mloskot/qt-creator-plugin-boostbuild Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
AMDG On 07/21/2017 03:32 PM, Mateusz Loskot via Boost wrote:
On 21 July 2017 at 21:53, Artyom Beilis via Boost <boost@lists.boost.org> wrote:
1. Support of basic features given by any normal REAL WORLD build system barely exists (library search configuration options etc) 2. Documentation isn't good and it was this for years. 3. Knowledge exits only for few people.
Do you want a proof? Please find me a tutorial how to search a 3rd part library or complete reference documentation for that.
I'd like to second Artyom's comments here. Boost.GIL may serve as another example - with I/O API depending on number of external libraries to support raster formats.
Back in 2010, during and long after the GIL review, I remember Christian Henning (author and maintainer of GIL) and myself, we were having hard times over long months trying to complete the Boost.Build setup for the library. I don't remember if eventually Christian released GIL with user friendly support for third-party libraries. I'd been trying to convince myself [1] to like Boost.Build Extensions [2] for some time.
I distinctly remember helping Christian with the Boost.Build support and the modules are present: https://github.com/boostorg/build/blob/develop/src/tools/libjpeg.jam https://github.com/boostorg/build/blob/develop/src/tools/libpng.jam https://github.com/boostorg/build/blob/develop/src/tools/libtiff.jam https://github.com/boostorg/build/blob/develop/src/tools/zlib.jam However, the actual test suite seems to be using those Boost.Build extensions you mentioned (In addition to hard-coding Christian's local paths). Usage: b2 -sZLIB_LIBRARY_PATH=XXX -sZLIB_INCLUDE=YYY -or- b2 -sZLIB_SOURCE=ZZZ -or- In user-config.jam: using zlib : 1.2.7 : <search>/a/path <include>/a/path ; -or- Do nothing and let zlib be found in the system path. Inside the Jamfile: import ac ; using zlib ; exe test : src.cpp : # If zlib is found... [ ac.check-library /zlib//zlib : # link to it and also include the sources that use it <library>/zlib//zlib <source>code-using-zlib.cpp ] ; In Christ, Steven Watanabe
On Fri, Jul 21, 2017 at 1:24 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
This, too, concerns me. b2 builds on everything, and is included in every boost distribution. It is apparently built with such consideration that I can use it on ridiculously old versions of gcc without breaking a sweat. In cyber security, when training individuals, you find yourself using ridiculously old machines. We need, therefore, to be able to build software on these old machines. Watching this decision play out, I have concerns that I won't be able to do things like build boost on a 10-year-old distribution of debian using static libraries (so they work on all distributions based on this debian release), while also building boost for Windows XP on VC++ 2013 in a way that allows certain projects with fiddly settings compiler properly, yet still build for other version of Windows on the more recent compilers with more sane settings. I fully expect turbulence in the coming conversion to CMake for my admittedly non-standard setup. My hope is that this happens in at a measured pace allowing for edge cases line mine to weigh in without stopping newer fixes and contributions from entering the distribution. If there's some way I can set up a series of automated tests, I'd like to help. (Yes, observant folks might notice that I've mentioned this before, and appeared not to follow up... I did actually try to set up automated testing, but ran into problems, then failed to follow up with anyone about those problems because I got distracted by my job... but if this is moving to CMake, I expect I need to help). - Trey
On Fri, Jul 21, 2017 at 1:47 PM, Joseph Van Riper via Boost < boost@lists.boost.org> wrote:
On Fri, Jul 21, 2017 at 1:24 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
This, too, concerns me.
b2 builds on everything, and is included in every boost distribution. It is apparently built with such consideration that I can use it on ridiculously old versions of gcc without breaking a sweat.
Again, CMake builds everywhere too. The latest version is 7.3MB. I don't think this particular issue is anything to worry about -- if people still want a bootstrapping Boost+CMake, it's trivial to do so. Zach
On 07/21/17 21:57, Zach Laine via Boost wrote:
On Fri, Jul 21, 2017 at 1:47 PM, Joseph Van Riper via Boost < boost@lists.boost.org> wrote:
On Fri, Jul 21, 2017 at 1:24 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
This, too, concerns me.
b2 builds on everything, and is included in every boost distribution. It is apparently built with such consideration that I can use it on ridiculously old versions of gcc without breaking a sweat.
Again, CMake builds everywhere too. The latest version is 7.3MB. I don't think this particular issue is anything to worry about -- if people still want a bootstrapping Boost+CMake, it's trivial to do so.
Downloading and installing binaries from the Internet is not a recommended practice in Linux world and not only there. In some environments this is simply not an option. So often you're stuck with the versions provided with your distro or the versions you build yourself. Building often pulls other dependencies, which may not be recent enough, so the amount of work piles up.
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
On Fri, Jul 21, 2017 at 2:30 PM, Alain Miniussi via Boost < boost@lists.boost.org> wrote:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
That's what I've been trying to say, though apparently not explicitly enough. Zach
Hi Alain, Am Freitag, 21. Juli 2017, 21:30:28 CEST schrieb Alain Miniussi via Boost:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
If Kitware changes CMake's license to the BGL, then yes. And repeat: CMake does not compile. It is a Meta-Build-System generating files for the real deal. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On 07/21/17 22:42, Jürgen Hunold via Boost wrote:
Hi Alain,
Am Freitag, 21. Juli 2017, 21:30:28 CEST schrieb Alain Miniussi via Boost:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
If Kitware changes CMake's license to the BGL, then yes.
Did you mean BSL (Boost Software License)? Yes, licensing is an issue, too.
And repeat: CMake does not compile. It is a Meta-Build-System generating files for the real deal.
Well, hopefully, it can generate Makefiles for an old enough GNU make, which should be everywhere, except Windows, which has VS projects... But yes, having an actual build system is also something to keep in mind.
On 21 July 2017 at 23:27, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
... except Windows, which has VS projects... But yes, having an actual build system is also something to keep in mind.
Although CMake can build VS-solutions, I don't think that boost should go this way. Having solutions with multiple projects (and boost will have many), is a night-mare, in case one (small) thing needs to be changed in all projects in that solution, good luck, have fun! This is the inherent weakness of the solutions/projects approach of VS, a linux-style approach is needed. IMHO, the only sensible way to use CMake (from the command-line, not the stupidly limited "IDE") with a (super-)project like boost on windows is to generate for and use nmake. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
AMDG On 07/21/2017 10:03 PM, degski via Boost wrote:
IMHO, the only sensible way to use CMake (from the command-line, not the stupidly limited "IDE") with a (super-)project like boost on windows is to generate for and use nmake.
The last time I checked, nmake doesn't support parallel builds, which makes it rather useless. In Christ, Steven Watanabe
On 22 July 2017 at 07:20, Steven Watanabe via Boost <boost@lists.boost.org> wrote:
The last time I checked, nmake doesn't support parallel builds, which makes it rather useless.
It seems (according to kitware <https://blog.kitware.com/cmake-building-with-all-your-cores/>) that JOM <http://download.qt.io/official_releases/jom/jom_1_1_2.zip> is the answer to that. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
Am 22.07.2017 um 06:38 schrieb degski via Boost:
On 22 July 2017 at 07:20, Steven Watanabe via Boost <boost@lists.boost.org> wrote:
It seems (according to kitware <https://blog.kitware.com/cmake-building-with-all-your-cores/>) that JOM <http://download.qt.io/official_releases/jom/jom_1_1_2.zip> is the answer to that.
Yet another dependency - yay! With every suggestion on how to get around deficiencies of CMake when it comes to actually build (and test) something things are getting more complicated. From my pov as a (almost daily) tester of both individual Boost libraries and all of Boost in different configurations, and as a Boost distro maintainer, this sounds like a growing nightmare when I compare it to the simplicity and ease-of-use of Boost.Build in those scenarios that I have to deal with. As an end-user, when it comes to consuming Boost libraries I don't care if it is Boost.Build, or CMake, or both, or whatever else because we use neither of them in our team. Ciao Dani
On 22/07/17 08:17, Daniela Engert via Boost wrote:
Am 22.07.2017 um 06:38 schrieb degski via Boost:
On 22 July 2017 at 07:20, Steven Watanabe via Boost <boost@lists.boost.org> wrote:
It seems (according to kitware <https://blog.kitware.com/cmake-building-with-all-your-cores/>) that JOM <http://download.qt.io/official_releases/jom/jom_1_1_2.zip> is the answer to that.
Yet another dependency - yay! With every suggestion on how to get around deficiencies of CMake when it comes to actually build (and test) something things are getting more complicated.
What CMake is providing here is choice and flexibility. If you want to build on Windows with no extra tools, you can use nmake or project/solution files. Both can be used directly from the command-line (nmake, msbuild) with no use of a GUI, but both are a bit slow and have no or limited parallelisation. You could use jom to speed up nmake Makefiles. Or you can choose to generate build files for something else entirely; personally on Windows I use Ninja due to its excellent parallelisation and speed compared with the others. The choice is up to the user to use an extra tool for speed, or the default tools for convenience. I don't see this flexibility as a bad thing; it's one of the big selling points for using CMake in the first place. Regards, Roger
On 22 July 2017 at 10:17, Daniela Engert via Boost <boost@lists.boost.org> wrote:
Yet another dependency - yay!
Thisisi a rather big word, isn't it? Just dump the exe in a folder included in the path and forget about it.
With every suggestion on how to get around deficiencies of CMake when it comes to actually build (and test) something things are getting more complicated.
It's a deficiency of nmake jom is fixing, not of CMake.
From my pov as a (almost daily) tester of both individual Boost libraries and all of Boost in different configurations, and as a Boost distro maintainer, this sounds like a growing nightmare when I compare it to the simplicity and ease-of-use of Boost.Build in those scenarios that I have to deal with.
Don't dis-agree with you there. Steven questioned the parallel capabilities of nmake, and apparently it's a real concern as somebody/some peops decided (and put the effort into it) they would offer an open source free utility to provide the parallelisation required. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
On 22/07/2017 10:29, degski via Boost wrote:
On 22 July 2017 at 10:17, Daniela Engert via Boost <boost@lists.boost.org> wrote:
Yet another dependency - yay!
Thisisi a rather big word, isn't it? Just dump the exe in a folder included in the path and forget about it.
With every suggestion on how to get around deficiencies of CMake when it comes to actually build (and test) something things are getting more complicated.
It's a deficiency of nmake jom is fixing, not of CMake.
Just to disagree, I think it's a deficiency (one of the biggest one) of CMake because CMake, as a "build" tool, does not support parallel builds because it depends on other build tools, including bad ones. I really don't understand why CMake can't build things directly, it's one of its biggest deficiencies. One of the most important requirements of a build tool is to build software *fast* and *portably*, without having to rely on other programs. Best, Ion
Just to disagree, I think it's a deficiency (one of the biggest one) of CMake because CMake, as a "build" tool, does not support parallel builds because it depends on other build tools, including bad ones. I really don't understand why CMake can't build things directly, it's one of its biggest deficiencies.
One of the most important requirements of a build tool is to build software *fast* and *portably*, without having to rely on other programs.
fwiw, systems like ninja [1] are designed to support fast and parallel builds, the syntax is designed for that use-case, and it is designed to be generated (by cmake or gyp). otoh, fast compile times are not necessarily the only requirement: parallel builds with ninja render windows unresponsive, so it are much more suited for buildservers (macos is better, linux doesn't have this issues). so as developer your productivity may be lower, even if the compile times are faster. otoh, developers who like IDEs may have a higher productivity due to debugger integration. [1] https://ninja-build.org/
AMDG On 07/24/2017 08:08 AM, Tim Blechmann via Boost wrote:
otoh, fast compile times are not necessarily the only requirement: parallel builds with ninja render windows unresponsive, so it are much more suited for buildservers (macos is better, linux doesn't have this issues). so as developer your productivity may be lower, even if the compile times are faster.
If you want to do other things while the build is running, then you should set the number of parallel jobs to something less than the number of cores, to leave some cycles free. In Christ, Steven Watanabe
Le 24/07/2017 à 17:52, Steven Watanabe via Boost a écrit :
If you want to do other things while the build is running, then you should set the number of parallel jobs to something less than the number of cores, to leave some cycles free. You can even tweak it with: -l N do not start new jobs if the load average is greater than N
On 24/07/2017 16:08, Tim Blechmann via Boost wrote:
Just to disagree, I think it's a deficiency (one of the biggest one) of CMake because CMake, as a "build" tool, does not support parallel builds because it depends on other build tools, including bad ones. I really don't understand why CMake can't build things directly, it's one of its biggest deficiencies.
One of the most important requirements of a build tool is to build software *fast* and *portably*, without having to rely on other programs.
fwiw, systems like ninja [1] are designed to support fast and parallel builds, the syntax is designed for that use-case, and it is designed to be generated (by cmake or gyp).
otoh, fast compile times are not necessarily the only requirement: parallel builds with ninja render windows unresponsive, so it are much more suited for buildservers (macos is better, linux doesn't have this issues). so as developer your productivity may be lower, even if the compile times are faster.
I usually run my library tests for dozens of configurations with a script that is launched with lower than normal priority and with -jN with N being 1.5 times the number of CPUs (I find compiling is many times IO-bounded). At least with a SSD disk, I can still do my low-cpu tasks like e-mail and browsing without any problem. I'm using windows, no idea if other OS/desktops have that problem. I wasn't talking about a build system that freezes your computer, but something that builds in parallel and always builds similarly in every OS. I'm afraid that if i need to have a different "build folder" for each configuration, project/make/ninja generation will take a considerable time that could be used just to compile and run my tests. Of course I don't consider any option that would force me to copy sources (say, the boost tree) to a different sandbox to avoid project/make/ninja generation conflicts, that would be simply crazy.
otoh, developers who like IDEs may have a higher productivity due to debugger integration.
Sure. At least in windows you can open an executable as a project with Visual Studio and debug it flawlessly. If there is a problem with a Boost.Build test, I can just drop the exe into the IDE and debug it without problems, if it has debug info (and in my local tests I activate debug symbols also in release, just in case). For Linux gdb -tui is what I use. Best, Ion
On Mon, 2017-07-24 at 22:18 +0200, Ion Gaztañaga via Boost wrote:
On 24/07/2017 16:08, Tim Blechmann via Boost wrote:
Just to disagree, I think it's a deficiency (one of the biggest one) of CMake because CMake, as a "build" tool, does not support parallel builds because it depends on other build tools, including bad ones. I really don't understand why CMake can't build things directly, it's one of its biggest deficiencies.
One of the most important requirements of a build tool is to build software *fast* and *portably*, without having to rely on other programs.
fwiw, systems like ninja [1] are designed to support fast and parallel builds, the syntax is designed for that use-case, and it is designed to be generated (by cmake or gyp).
otoh, fast compile times are not necessarily the only requirement: parallel builds with ninja render windows unresponsive, so it are much more suited for buildservers (macos is better, linux doesn't have this issues). so as developer your productivity may be lower, even if the compile times are faster.
I usually run my library tests for dozens of configurations with a script that is launched with lower than normal priority and with -jN with N being 1.5 times the number of CPUs (I find compiling is many times IO-bounded). At least with a SSD disk, I can still do my low-cpu tasks like e-mail and browsing without any problem. I'm using windows, no idea if other OS/desktops have that problem.
I wasn't talking about a build system that freezes your computer, but something that builds in parallel and always builds similarly in every OS. I'm afraid that if i need to have a different "build folder" for each configuration, project/make/ninja generation will take a considerable time that could be used just to compile and run my tests.
The configuration is only ran once, initially, and doesn't take considerable time.
Of course I don't consider any option that would force me to copy sources (say, the boost tree) to a different sandbox to avoid project/make/ninja generation conflicts, that would be simply crazy.
Yea, no one is talking about copying the sources. This is about multiple build directories, but the source tree is the same.
I usually run my library tests for dozens of configurations with a script that is launched with lower than normal priority and with -jN with N being 1.5 times the number of CPUs (I find compiling is many times IO-bounded). At least with a SSD disk, I can still do my low-cpu tasks like e-mail and browsing without any problem. I'm using windows, no idea if other OS/desktops have that problem.
nmake, jom or ninja -jN? jom for example doesn't keep the cores as busy as ninja in my experience. but it was just an artificial example that there are plain build performance is not only aspect to consider ... also some applications (sublime text and conemu for example) seem to perform much worse under load than others
otoh, developers who like IDEs may have a higher productivity due to debugger integration.
Sure. At least in windows you can open an executable as a project with Visual Studio and debug it flawlessly. If there is a problem with a Boost.Build test, I can just drop the exe into the IDE and debug it without problems, if it has debug info (and in my local tests I activate debug symbols also in release, just in case). For Linux gdb -tui is what I use.
if you drop the exe into the ide, you can debug, but does it run the executable with specific command line options in a specific working directory in a specific environment? and/or does it populate a project with source files involved and does it create a code model to allow source navigation as in native msvc project files? debugging may be possible, but the UX will probably differ ... the point is not necessarily that something is possible, but that some people prefer one workflow, but others prefer another (at least i've learned this lesson from converting 2.5 companies with non-trivial buildsystems to cmake).
Am 25.07.2017 um 00:04 schrieb Tim Blechmann via Boost:
otoh, developers who like IDEs may have a higher productivity due to debugger integration.
Sure. At least in windows you can open an executable as a project with Visual Studio and debug it flawlessly.
if you drop the exe into the ide, you can debug, but does it run the executable with specific command line options in a specific working directory in a specific environment? Yes, that's totally up to you.
and/or does it populate a project with source files involved No it does not. It treats the binaries as kind of a project file.
and does it create a code model to allow source navigation as in native msvc project files? Yes, I can see no difference here.
debugging may be possible, but the UX will probably differ ... It does: the solution explorer window is mostly empty. Besides that you see no difference in UI and behaviour.
Ciao Dani
otoh, developers who like IDEs may have a higher productivity due to debugger integration.
Sure. At least in windows you can open an executable as a project with Visual Studio and debug it flawlessly.
if you drop the exe into the ide, you can debug, but does it run the executable with specific command line options in a specific working directory in a specific environment? Yes, that's totally up to you.
but i suppose that a user has to set this up manually as it is not defined in the build definition
and/or does it populate a project with source files involved No it does not. It treats the binaries as kind of a project file.
and does it create a code model to allow source navigation as in native msvc project files? Yes, I can see no difference here.
debugging may be possible, but the UX will probably differ ... It does: the solution explorer window is mostly empty. Besides that you see no difference in UI and behaviour.
... also what about xcode or clion or qtcreator? or running the IDE-integrated static analysis tools on a codebase? or libclang based tools that use a json compile database?
On 07/25/17 11:56, Tim Blechmann via Boost wrote:
otoh, developers who like IDEs may have a higher productivity due to debugger integration.
Sure. At least in windows you can open an executable as a project with Visual Studio and debug it flawlessly.
if you drop the exe into the ide, you can debug, but does it run the executable with specific command line options in a specific working directory in a specific environment? Yes, that's totally up to you.
but i suppose that a user has to set this up manually as it is not defined in the build definition
and/or does it populate a project with source files involved No it does not. It treats the binaries as kind of a project file.
and does it create a code model to allow source navigation as in native msvc project files? Yes, I can see no difference here.
debugging may be possible, but the UX will probably differ ... It does: the solution explorer window is mostly empty. Besides that you see no difference in UI and behaviour.
... also what about xcode or clion or qtcreator? or running the IDE-integrated static analysis tools on a codebase? or libclang based tools that use a json compile database?
On Linux, references to sources are typically stored in debug symbols. So, as long as you have sources at the same location as when the executable was built, and the debug symbols include a full path, you should be able to view the source code. But you don't get the full code model (with the ability to navigate the project or follow symbols) unless you also open the project in the IDE because there is no information about include directories or defined macros. I might be mistaken, but the situation was similar on Windows AFAIR.
On 22 July 2017 at 11:27, Peter Dimov via Boost <boost@lists.boost.org> wrote:
degski wrote:
IMHO, the only sensible way to use CMake (from the command-line, not the
stupidly limited "IDE") with a (super-)project like boost on windows is to generate for and use nmake.
MSBuild, rather.
But MSBuild still builds solutions and projects, no? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
degski wrote:
On 22 July 2017 at 11:27, Peter Dimov via Boost <boost@lists.boost.org> wrote:
degski wrote:
IMHO, the only sensible way to use CMake (from the command-line, not the stupidly limited "IDE") with a (super-)project like boost on windows is to generate for and use nmake.
MSBuild, rather.
But MSBuild still builds solutions and projects, no?
Who cares, you just say cmake --build . and it does its stuff. :-)
On 22 July 2017 at 11:45, Peter Dimov via Boost <boost@lists.boost.org> wrote:
But MSBuild still builds solutions and projects, no?
Who cares, you just say cmake --build . and it does its stuff. :-)
Could be fun to see how long it takes to open/intialize a (I'm just putting a number, 130 libs + their tests) a 250+ projects solution (no pun intended) with an endless number of dependencies. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
There are many build tools you can use to build using CMake on Windows. Ninja is one choice, but if you choose to generate VS project files, you still have multiple options. MSBuild supports parallel builds just fine (it was able to handle our 40 core build machine with no problems at my last job). You can also invoke the command-line version of Visual Studio's compiler directly, again, also with parallel builds with no problem. I found that this was surprisingly faster than using MSBuild, but I was never able to find out if this is true in general or just an artifact of our build environment. In other words, there is no "extra dependency" involved here. There are other tools that the user can choose to use as their generator if they care (and we do not care which generator they use), but as long as they meet the minimum requirements of having compiler installed, you can use cmake --build to build it. Perhaps some of the confusion about whether this can be done is parallel comes from the fact that by default, this command will not always invoke a parallel build (it uses whatever defaults of the generated target is, which for some systems is a single job). For such build systems as the backend, unfortunately the user has to invoke the command as `cmake --build -- /maxcpucount` (typing from memory), unless this has changed in newer versions?
IMHO, the only sensible way to use CMake (from the command-line, not the stupidly limited "IDE") with a (super-)project like boost on windows is to generate for and use nmake.
ninja (https://ninja-build.org) works like charm on multiple platforms. fwiw, cmake and b2 have different architecture as one is a build system the other is a generator for build systems. both have advantages and disadvantages.
Tim Blechmann wrote:
fwiw, cmake and b2 have different architecture as one is a build system the other is a generator for build systems.
I wonder how many of the people who repeat this mantra understand either Boost.Build or CMake. CMake does not generate build _systems_, it generates build _scripts_. So does, incidentally, Boost.Build, which is a major reason why it's so hard to understand.
fwiw, cmake and b2 have different architecture as one is a build system the other is a generator for build systems.
I wonder how many of the people who repeat this mantra understand either Boost.Build or CMake.
CMake does not generate build _systems_, it generates build _scripts_.
generated project files are a bit more than *build scripts*, as integration into IDEs like msvc, xcode or qtcreator provide a UX similar to native project files (debuggers / profilers / static analysis etc).
On 07/21/17 22:30, Alain Miniussi wrote:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
There's the build dependencies of cmake on Ubuntu: libarchive-dev (>= 2.8.0), libbz2-dev, libcurl4-openssl-dev | libcurl-ssl-dev, libexpat1-dev, libjsoncpp-dev, liblzma-dev, libncurses5-dev, libuv1-dev, procps [!hurd-any], python-sphinx, qtbase5-dev <!stage1>, zlib1g-dev (I've omitted the ones obviously required by Debian build scripts.) Are you going to include those as well?
On 21/07/2017 22:22, Andrey Semashev via Boost wrote:
On 07/21/17 22:30, Alain Miniussi wrote:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
There's the build dependencies of cmake on Ubuntu:
libarchive-dev (>= 2.8.0), libbz2-dev, libcurl4-openssl-dev | libcurl-ssl-dev, libexpat1-dev, libjsoncpp-dev, liblzma-dev, libncurses5-dev, libuv1-dev, procps [!hurd-any], python-sphinx, qtbase5-dev <!stage1>, zlib1g-dev
(I've omitted the ones obviously required by Debian build scripts.)
Are you going to include those as well?
All the required dependencies (beside OpenSSL for cURL) are included with the CMake sources and it will optionally use those. Note that some libraries are also only used for some features that are non essential, for example libuv is only for the "server" mode of CMake for better integration with IDEs, Qt is used for the Qt client...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 07/21/2017 10:28 PM, Florent Castelli via Boost wrote:
On 21/07/2017 22:22, Andrey Semashev via Boost wrote:
On 07/21/17 22:30, Alain Miniussi wrote:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform. We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
There's the build dependencies of cmake on Ubuntu: [...]
Are you going to include those as well?
All the required dependencies (beside OpenSSL for cURL) are included with the CMake sources and it will optionally use those.
We had problems with using the CMake versions of eg. cURL in our company and switched to using the system libraries. I think this might have to do with missing OpenSSL but cURL without TLS support is pretty useless today. So we were not able to build our own (usable) CMake without using system libraries.
On 25/07/2017 09:06, Norbert Wenzel via Boost wrote:
On 07/21/2017 10:28 PM, Florent Castelli via Boost wrote:
On 21/07/2017 22:22, Andrey Semashev via Boost wrote:
On 07/21/17 22:30, Alain Miniussi wrote:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform. We could embed the required CMake distribution in boost, compile it, and use it to build boost ? There's the build dependencies of cmake on Ubuntu: [...]
Are you going to include those as well? All the required dependencies (beside OpenSSL for cURL) are included with the CMake sources and it will optionally use those. We had problems with using the CMake versions of eg. cURL in our company and switched to using the system libraries. I think this might have to do with missing OpenSSL but cURL without TLS support is pretty useless today. So we were not able to build our own (usable) CMake without using system libraries.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It depends on the context. Will Boost's CMake reference anything over HTTPS or will it be self-contained? Probably self contained, so that wouldn't be a problem. If you require a full version of CMake, it is possible to build it using your system cURL, which isn't too difficult to build either.
On 21/07/2017 22:22, Andrey Semashev wrote:
On 07/21/17 22:30, Alain Miniussi wrote:
On 21/07/2017 19:24, Andrey Semashev via Boost wrote:
Actually, as a user I do care and not in favor of CMake because there is always a possibility that Boost requires a newer CMake version that is not available on my platform.
We could embed the required CMake distribution in boost, compile it, and use it to build boost ?
There's the build dependencies of cmake on Ubuntu:
libarchive-dev (>= 2.8.0), libbz2-dev, libcurl4-openssl-dev | libcurl-ssl-dev, libexpat1-dev, libjsoncpp-dev, liblzma-dev, libncurses5-dev, libuv1-dev, procps [!hurd-any], python-sphinx, qtbase5-dev <!stage1>, zlib1g-dev
(I've omitted the ones obviously required by Debian build scripts.)
Are you going to include those as well?
I don't remember having to install anything when building cmake from source in years (including 3.9.0 right now), either on my machines or the ones I had no admin right. So I don't expect that to be an issue.
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD. What I'm proposing can indeed be seen as one step towards the multiplication of tools. But that would be quite a few steps down the road, while what I'm saying here is that the step I propose above seems to me to be essential to overcome the current stalemate. Now assuming we progress somewhat using the above, with some libraries having transitioned to using CMake, while others still using Boost.Build, we have two choices: a) Test everything, and come to the conclusion that it works well enough for users, so we can make another release, or b) decide that we need to hold back the next release until the remaining libraries have switched.
Besides, I have my doubts regarding the technical feasibility of this heterogenous infrastructure as well. I'm sure there will be quirks and points of incompatibiliy between the different build systems or some seemingly unreasonable limitations that follow from this integration that will leave someone, possibly users, unhappy.
So you think we can't transition one library at a time, but you believe it will be possible to do a switch for 100+ libraries synchronously ? Sorry, but I can't follow your reasoning...
I wasn't referring to the transition process but rather the resulting model adopted by Boost. If that model includes multiple build systems then it is bound to have problems stemming from the integration.
Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job.
I don't share your (apparent) mental model of software, or the practice of software engineering. Software in general, and Boost libraries in particular, live from the respective communities of people maintaining and developing them. You can't just ask arbitrary "interested people" that aren't already part of those communities to do "a job" on the software. First, that's highly disrespectful of those who have been working on and with the software being changed. And more importantly, you aren't even addressing the real problem, of who would be responsible for the maintenance of that new software ? Who would help users getting stuck trying to build the library ? Who would fix issues ? The only possible answer is "the community". So I think the only people who can be reasonably expected to implement the change are actual members of said communities. And if they aren't willing to go into the imposed direction, there is very little you can do, if you don't want to risk a project fork.
A step by step switch adds a period (potentially, open-ended) when people have to maintain both build systems. As a Boost developer, I'm not happy about that. As a user, I might not be happy either, if one of the build systems doesn't actually work in a Boost release.
Well, if it doesn't work, don't switch ! A switch would obviously only be useful if it improves upon the status quo.
Regarding CMake as a candidate build system, I'm not convinced that the switch would benefit Boost in terms of "new blood" or something. I don't think the build system is something that is keeping millions of developers out there from contributing to Boost, as being advertised. It might be one, though probably not the major point, but I don't think anything will change e.g. wrt. maintenance if we switch right now. Most of the work doesn't even touch the build system or comes down to copying and pasting a piece of jamfile.
I recognize that CMake has gained popularity and it is easier to find support for it online. But I know that more than once I've been puzzled about how to do one thing or the other in it, much like with Boost.Build. So as a Boost developer, there may be a slight plus on CMake side for me, but absolutely not worth the damage that has been inflicted on Boost already on the road to it. As a Boost user I really don't care as I never ever integrate third party projects into my project build system as I consider that a broken approach in the first place.
Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
What I'm proposing can indeed be seen as one step towards the multiplication of tools. But that would be quite a few steps down the road, while what I'm saying here is that the step I propose above seems to me to be essential to overcome the current stalemate. Now assuming we progress somewhat using the above, with some libraries having transitioned to using CMake, while others still using Boost.Build, we have two choices: a) Test everything, and come to the conclusion that it works well enough for users, so we can make another release, or b) decide that we need to hold back the next release until the remaining libraries have switched.
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job.
I don't share your (apparent) mental model of software, or the practice of software engineering. Software in general, and Boost libraries in particular, live from the respective communities of people maintaining and developing them. You can't just ask arbitrary "interested people" that aren't already part of those communities to do "a job" on the software.
Sure. Those "interested people" would be members of the community. Alternatively, these could be paid individuals acting on behalf of the community, but I think this is unlikely to happen.
First, that's highly disrespectful of those who have been working on and with the software being changed. And more importantly, you aren't even addressing the real problem, of who would be responsible for the maintenance of that new software ? Who would help users getting stuck trying to build the library ? Who would fix issues ?
Whatever plan you propose, nothing will happen unless all library developers are on board. This is an obvious implied pre-requisite. Doing it the other way will only leave you with a pile of dead code and no maintainers. The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way. There's nothing disrespectful in this approach. It would be disrespectful if the SC or someone with universal commit permissions imposed CMake on everyone. Which is why the latest announcement from the SC is a big mistake, to put it mildly.
On 21.07.2017 16:15, Andrey Semashev via Boost wrote:
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
The allusion to things not going to work for Boost users, unless the entirety of Boost has migrated to CMake. It's this claim that has taken the actual community hostage, as it requires either a buy-in from everyone (not going to happen), or some higher power to impose the change (which likewise isn't going to work out in the long term, even if it might initially look like progress).
What I'm proposing can indeed be seen as one step towards the multiplication of tools. But that would be quite a few steps down the road, while what I'm saying here is that the step I propose above seems to me to be essential to overcome the current stalemate. Now assuming we progress somewhat using the above, with some libraries having transitioned to using CMake, while others still using Boost.Build, we have two choices: a) Test everything, and come to the conclusion that it works well enough for users, so we can make another release, or b) decide that we need to hold back the next release until the remaining libraries have switched.
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
Not sure what you have in mind with "half-baked support for CMake".
Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job.
I don't share your (apparent) mental model of software, or the practice of software engineering. Software in general, and Boost libraries in particular, live from the respective communities of people maintaining and developing them. You can't just ask arbitrary "interested people" that aren't already part of those communities to do "a job" on the software.
Sure. Those "interested people" would be members of the community. Alternatively, these could be paid individuals acting on behalf of the community, but I think this is unlikely to happen.
Indeed, because...
First, that's highly disrespectful of those who have been working on and with the software being changed. And more importantly, you aren't even addressing the real problem, of who would be responsible for the maintenance of that new software ? Who would help users getting stuck trying to build the library ? Who would fix issues ?
Whatever plan you propose, nothing will happen unless all library developers are on board. This is an obvious implied pre-requisite. Doing it the other way will only leave you with a pile of dead code and no maintainers.
...of this. So the only possible way forward requires the individual communities to agree. (And I do prefer to talk about communities in plural - it's an illusion to think of a single "boost community". There are many, heterogeneous ones, with quite different requirements.
The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way.
Don't force anyone !
There's nothing disrespectful in this approach. It would be disrespectful if the SC or someone with universal commit permissions imposed CMake on everyone. Which is why the latest announcement from the SC is a big mistake, to put it mildly.
Oh, so we actually agree - or almost. :-) It seems the main difference is that you think the burden is the required work to switch, while to me it's the maintenance work after the switch. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 07/21/17 23:28, Stefan Seefeld via Boost wrote:
On 21.07.2017 16:15, Andrey Semashev via Boost wrote:
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
The allusion to things not going to work for Boost users, unless the entirety of Boost has migrated to CMake.
This is not what I was saying. I was saying that the model of each library using its own build system won't work well for users.
It's this claim that has taken the actual community hostage, as it requires either a buy-in from everyone (not going to happen),
If people don't agree to switch then the transition is not going to happen. Either that or those people will follow Rene's example.
or some higher power to impose the change (which likewise isn't going to work out in the long term, even if it might initially look like progress).
Right.
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
Not sure what you have in mind with "half-baked support for CMake".
It means with CMake transition unfinished. Not all libraries converted, non-functional build/test/docs with CMake, etc.
The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way.
Don't force anyone !
Not sure what you mean. Noone's forcing anyone. Well, except the SC after the announcement. I'll paraphrase my point, in case if I failed to communicate. Basically, a Boost maintainer has the following options: 0. Actively help the transition and maintenance of CMake afterwards. 1. Accept the burden of maintaining CMake for his library. Depending on the migration plan and the final model, CMake may be the only build system to maintain or be an addition to Boost.Build. 2. Resign from maintenance. 3. Actively object migrating their particular library, leaving Boost multi-build-system. 4. Despite the SC the community decides not to switch to CMake and everything is kept as is. Everyone are free to pick their poison.
There's nothing disrespectful in this approach. It would be disrespectful if the SC or someone with universal commit permissions imposed CMake on everyone. Which is why the latest announcement from the SC is a big mistake, to put it mildly.
Oh, so we actually agree - or almost. :-) It seems the main difference is that you think the burden is the required work to switch, while to me it's the maintenance work after the switch.
Both are, and both require volunteers.
On 21.07.2017 17:35, Andrey Semashev via Boost wrote:
On 07/21/17 23:28, Stefan Seefeld via Boost wrote:
On 21.07.2017 16:15, Andrey Semashev via Boost wrote:
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
The allusion to things not going to work for Boost users, unless the entirety of Boost has migrated to CMake.
This is not what I was saying. I was saying that the model of each library using its own build system won't work well for users. But in this thread I'm not proposing each library to use "its own build system". I'm proposing to allow each library to choose whether to move to CMake or to stay with Boost.Build, as an attempt to unlock the current gridlock.
It's this claim that has taken the actual community hostage, as it requires either a buy-in from everyone (not going to happen),
If people don't agree to switch then the transition is not going to happen. Either that or those people will follow Rene's example.
That's the problem. Some people are frustrated if they have to move, other are frustrated if they have to stay. Thus an "either or" scenario can't be the answer.
or some higher power to impose the change (which likewise isn't going to work out in the long term, even if it might initially look like progress).
Right.
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
Not sure what you have in mind with "half-baked support for CMake".
It means with CMake transition unfinished. Not all libraries converted, non-functional build/test/docs with CMake, etc.
But if some projects complete the transition, there isn't anything "unfinished", at least not if the infrastructure is set up to support this. It's what's called incremental progress. To paraphrase: it's better to have x% of the libraries converted 100% than 100% of the libraries converted x%.
The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way.
Don't force anyone !
Not sure what you mean. Noone's forcing anyone. Well, except the SC after the announcement.
Huh, now it's me who isn't sure what you mean :-) Can you please rephrase this last set of sentences ? I'm not sure what you are trying to say here. :-)
I'll paraphrase my point, in case if I failed to communicate. Basically, a Boost maintainer has the following options:
0. Actively help the transition and maintenance of CMake afterwards.
1. Accept the burden of maintaining CMake for his library. Depending on the migration plan and the final model, CMake may be the only build system to maintain or be an addition to Boost.Build.
2. Resign from maintenance.
3. Actively object migrating their particular library, leaving Boost multi-build-system.
4. Despite the SC the community decides not to switch to CMake and everything is kept as is.
Everyone are free to pick their poison.
Again, not sure what your point is in listing these options. To me it seems clear that the SC is asking us to pick between 0. and 1., while I propose 3.
There's nothing disrespectful in this approach. It would be disrespectful if the SC or someone with universal commit permissions imposed CMake on everyone. Which is why the latest announcement from the SC is a big mistake, to put it mildly.
Oh, so we actually agree - or almost. :-) It seems the main difference is that you think the burden is the required work to switch, while to me it's the maintenance work after the switch.
Both are, and both require volunteers.
So ? Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 07/22/17 00:48, Stefan Seefeld via Boost wrote:
On 21.07.2017 17:35, Andrey Semashev via Boost wrote:
On 07/21/17 23:28, Stefan Seefeld via Boost wrote:
On 21.07.2017 16:15, Andrey Semashev via Boost wrote:
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
The allusion to things not going to work for Boost users, unless the entirety of Boost has migrated to CMake.
This is not what I was saying. I was saying that the model of each library using its own build system won't work well for users. But in this thread I'm not proposing each library to use "its own build system". I'm proposing to allow each library to choose whether to move to CMake or to stay with Boost.Build, as an attempt to unlock the current gridlock.
Right. For users, that would be somewhat better than everyone using their own build system, but the problems that I described in my original reply in this thread remain. Again, I think for many users half CMake-based half Boost.Build-based Boost distribution would be more difficult to use than just CMake-based or just Boost.Build-based distribution.
The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way.
Don't force anyone !
Not sure what you mean. Noone's forcing anyone. Well, except the SC after the announcement.
Huh, now it's me who isn't sure what you mean :-) Can you please rephrase this last set of sentences ? I'm not sure what you are trying to say here. :-)
I was coming from the premise of Boost migrating to CMake as a whole, which is what I think is being suggested by the SC. In this scenario, each maintainer has the options I listed below.
0. Actively help the transition and maintenance of CMake afterwards.
1. Accept the burden of maintaining CMake for his library. Depending on the migration plan and the final model, CMake may be the only build system to maintain or be an addition to Boost.Build.
2. Resign from maintenance.
3. Actively object migrating their particular library, leaving Boost multi-build-system.
4. Despite the SC the community decides not to switch to CMake and everything is kept as is.
Everyone are free to pick their poison.
On 21/07/2017 22:15, Andrey Semashev via Boost wrote:
On 07/21/17 21:58, Stefan Seefeld via Boost wrote:
On 21.07.2017 13:10, Andrey Semashev via Boost wrote:
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
I'm sure it's been mentioned before by someone, but as a Boost user and packager (for my work projects) I don't want to deal with a dozen of build systems (worse yet - multiple versions of the same build system) to be able to build Boost. Having a single build system, a single interface and customization point is an important advantage regardless of what the actual build system is used.
Don't you realize how impossible this has become, given the current size and scale of Boost ? You can't treat a project like Boost, with > 100 individual libraries in it, as a single entity. It's not going to work. And each attempt to impose a change will result in endless discussions leading nowhere. We have to face this reality, and break Boost up into parts that individually are amenable to such change. But not as a single orchestrated switch.
Also, please note that I did not suggest that we open the door for any other build systems (though that certainly could become an interesting discussion later).
I think you did advocate for the model where each library picks its own tools, including the build system. Allowing two build systems would be just the first step. I'm just saying that this won't work well for Boost users, at least not for a significant part of them.
That's just FUD.
What exactly in my message is FUD?
What I'm proposing can indeed be seen as one step towards the multiplication of tools. But that would be quite a few steps down the road, while what I'm saying here is that the step I propose above seems to me to be essential to overcome the current stalemate. Now assuming we progress somewhat using the above, with some libraries having transitioned to using CMake, while others still using Boost.Build, we have two choices: a) Test everything, and come to the conclusion that it works well enough for users, so we can make another release, or b) decide that we need to hold back the next release until the remaining libraries have switched.
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
You could possibly ask developers from other major project who transitioned to CMake what was their experience. LLVM moved exclusively to CMake not too long ago and it would certainly be interesting for people doubting it is possible to talk to their build engineers and developers. Note that some people (certainly not everyone) are quite happy with the transition, I saw again some message the other day from people loving the new changes in the latest CMake and it made LLVM compile much faster.
Regarding the transition process (to whatever build system, not necessarilly CMake), I think both ways have its merits. Making a whole-Boost switch is more resource expensive, but not impossible if there are enough interested people with enough permissions to do the job.
I don't share your (apparent) mental model of software, or the practice of software engineering. Software in general, and Boost libraries in particular, live from the respective communities of people maintaining and developing them. You can't just ask arbitrary "interested people" that aren't already part of those communities to do "a job" on the software.
Sure. Those "interested people" would be members of the community. Alternatively, these could be paid individuals acting on behalf of the community, but I think this is unlikely to happen.
First, that's highly disrespectful of those who have been working on and with the software being changed. And more importantly, you aren't even addressing the real problem, of who would be responsible for the maintenance of that new software ? Who would help users getting stuck trying to build the library ? Who would fix issues ?
Whatever plan you propose, nothing will happen unless all library developers are on board. This is an obvious implied pre-requisite. Doing it the other way will only leave you with a pile of dead code and no maintainers.
The particular developers may not be willing or have the resource or knowledge to do the actual transition, but it should be evident to everyone that if and when the transition is complete (by those interested champions willing to do the job), the maintenance burden is left upon the particular library maintainers. This is similar to how it happened with git and I see no other way.
I'm certain there will be build engineers like myself and many others willing to send PR to transition libraries to CMake once a design has been chosen. Then it's up to the library owners to merge them in due time.
There's nothing disrespectful in this approach. It would be disrespectful if the SC or someone with universal commit permissions imposed CMake on everyone. Which is why the latest announcement from the SC is a big mistake, to put it mildly.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 21.07.2017 16:35, Florent Castelli via Boost wrote:
On 21/07/2017 22:15, Andrey Semashev via Boost wrote:
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
You could possibly ask developers from other major project who transitioned to CMake what was their experience. LLVM moved exclusively to CMake not too long ago and it would certainly be interesting for people doubting it is possible to talk to their build engineers and developers. Note that some people (certainly not everyone) are quite happy with the transition, I saw again some message the other day from people loving the new changes in the latest CMake and it made LLVM compile much faster. All this is beside the point, as we are not arguing about the respective advantages or disadvantages in Boost.Build or CMake. The point is about who has the burden to a) implement the change and b) to maintain the infrastructure, and how that affects (or should affect) the decision making process.
Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 21/07/2017 22:55, Stefan Seefeld via Boost wrote:
On 21.07.2017 16:35, Florent Castelli via Boost wrote:
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems. You could possibly ask developers from other major project who
On 21/07/2017 22:15, Andrey Semashev via Boost wrote: transitioned to CMake what was their experience. LLVM moved exclusively to CMake not too long ago and it would certainly be interesting for people doubting it is possible to talk to their build engineers and developers. Note that some people (certainly not everyone) are quite happy with the transition, I saw again some message the other day from people loving the new changes in the latest CMake and it made LLVM compile much faster. All this is beside the point, as we are not arguing about the respective advantages or disadvantages in Boost.Build or CMake. The point is about who has the burden to a) implement the change and b) to maintain the infrastructure, and how that affects (or should affect) the decision making process.
No this is directly commenting on this point. LLVM did a gradual transition, they survived and are moving forward. If someone questions the possibility of doing the same, then they can just ask them how they did it. Remember they probably have way more developers working on it than Boost itself and a successful migration.
Stefan
On 07/22/17 00:10, Florent Castelli via Boost wrote:
On 21/07/2017 22:55, Stefan Seefeld via Boost wrote:
On 21.07.2017 16:35, Florent Castelli via Boost wrote:
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems. You could possibly ask developers from other major project who
On 21/07/2017 22:15, Andrey Semashev via Boost wrote: transitioned to CMake what was their experience. LLVM moved exclusively to CMake not too long ago and it would certainly be interesting for people doubting it is possible to talk to their build engineers and developers. Note that some people (certainly not everyone) are quite happy with the transition, I saw again some message the other day from people loving the new changes in the latest CMake and it made LLVM compile much faster. All this is beside the point, as we are not arguing about the respective advantages or disadvantages in Boost.Build or CMake. The point is about who has the burden to a) implement the change and b) to maintain the infrastructure, and how that affects (or should affect) the decision making process.
No this is directly commenting on this point. LLVM did a gradual transition, they survived and are moving forward. If someone questions the possibility of doing the same, then they can just ask them how they did it. Remember they probably have way more developers working on it than Boost itself and a successful migration.
I don't question that the transition can be done in principle. I don't think it can be done in the time span of one Boost release, which is about 4 months.
On 07/21/17 23:35, Florent Castelli via Boost wrote:
On 21/07/2017 22:15, Andrey Semashev via Boost wrote:
I don't think it is realistic to convert the whole Boost in a single release time frame, unless you want to put the transition as a release criteria (which would be a bad idea). It would make sense to either release half-baked support for CMake for a few Boost releases or to follow the switch-the-whole-Boost approach: work on libraries in the background and then merge it to develop/master for all libraries. In the former case there's that potentially endless period of having two build systems.
You could possibly ask developers from other major project who transitioned to CMake what was their experience. LLVM moved exclusively to CMake not too long ago and it would certainly be interesting for people doubting it is possible to talk to their build engineers and developers. Note that some people (certainly not everyone) are quite happy with the transition, I saw again some message the other day from people loving the new changes in the latest CMake and it made LLVM compile much faster.
I don't follow LLVM development and not familiar with their specifics, but I suspect their organization is different from Boost. Do they have 100+ more or less independent libraries, each having its maintainers and preferences, with no central government?
On 7/21/17 8:57 AM, Stefan Seefeld via Boost wrote:
On 21.07.2017 10:21, Thomas Heller via Boost wrote:
Hi list,
After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake.
Mostly, yes. And in addition, people are very polarized (even more so as a result of this ongoing discussion). So to frame the question as "should we stay with Boost.Build or should we move to CMake" is extremely counter-productive.
We need a way to continue to draw from the wealth of expertise encoded in the existing Boost.Build infrastructure as well as the community around it, while at the same time being open to change (in general, not just towards alternative build tools). To invoke a higher authority to decide to get out of this stalemate is foolish, as it entirely ignores both how Open Source works in general (you can't coerce people into doing things they aren't motivated to do to begin with), as well as the real reason for the stalemate: it's due to an artificial dichotomy: either Boost.Build or CMake, globally, for everyone at once.
Here is (once again) how I would approach this instead:
* Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals).
This is already in place. I all the time. Here is what I do: a) I make a change to some library b) I cd to the test directory of the library c) I invoke b2 to build and run the tests (I do this through the library_test macro in boost/tools, but that's not essential). d) the b2 build any dependent libraries and runs the tests of the library I'm working on.
* Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic.
This is what the top level build logic does. I once posted a simple shell script which would do exactly that. I turned out that this didn't work because the top level system had some library specific logic in it to accomodate some libraries which "do their own thing". I noted at the time that it was a mistake to do this and that library authors should have committed to boost requirements rather than the other way around.
* With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities.
This is indeed possible. In fact its quite easy. I created CMake CMakeList.txt files for the serialization libary - which has a very complex testing regimen. It's also not header only and supports a lot of variants, static, debug, the works. The safe numerics version even supports the CDash functionality which would be very useful to boost. I didn't like the way CMake implemented though. I did this because I wanted to be able to create an IDE for editing, testing and debugging the library. It's very easy for anyone who is interested to invoke CMake in the serialization directory, build and IDE and open it up and see what you get. So far as I know - only one person has actually done this.
Does this process appeal to anyone ?
Makes total sense to me. There are a couple of I haven't addressed because I haven't need them. a) The CDash functionality - needs a much better solution c) The CPack - packager - I have never figured out the utility of this c) FindBoostSerialization library. THis might be interesting to users or maybe not. When I use Boost in a CMake project I use FindBoost. This doesn't really work, but with some horsing around it can be made to work. There are lots of opinions on this thread amounting to saying "Here is what needs to be done - Developers (or someone else) should be forced to do it". This has gone nowhere and is not going anywhere. The SC can make any pronouncement it wants, but that's all its going to be until someone actually DOES something. The closed I've seen are my pages on CMake in the incubator and Peter Dimovs CMake proposal (which I haven't had time to study). Other than that ... nothing of substance. Robert Ramey
On 7/21/17 8:57 AM, Stefan Seefeld via Boost wrote:
On 21.07.2017 10:21, Thomas Heller via Boost wrote:
* Improve the existing Boost.Build infrastructure to allow libraries to be built stand-alone. (I remember from discussing with Rene a year ago that he had some work in progress to achieve this, so I don't think this is particularly hard, at least not for someone understanding Boost.Build internals).
Hmmm - I don't see the problem here. In fact, I do it all the time! I cd to the libs/test directory and invoke b2 ... Then I take a bathroom break. When I come back, I find that a) the serialization library has been built b) those (and only ) those other libraries required for either the serialization library or it's tests have been built c) all the tests have been run d) since I include library_test, I have a html table detailing all the test results. In a word - this is already done has been for at least 15 years!
* Replace the top-level build logic to simply iterate over all libraries, invoking this stand-alone build logic.
Right - not hard to do. I once submitted shell script to do exactly that. Problem was, Rene has been too accommodating to boost developers and has permitted a number of them to make their own rules. This should be addressed in any case. In short, this is not a problem.
* With the above in place, it becomes possible to switch from Boost.Build to CMake one library at a time, so the original question can be reframed as "which library wants to switch from Boost.Build to CMake", which, I'm sure, will be much less disruptive (if at all) and non-controversial, as the people to decide will be project maintainers and communities.
Right - More than that, this is the only way such a transition is even possible.
Does this process appeal to anyone ?
I don't think anyone actually has a rational alternative.
Regards, Stefan
Robert Ramey
On 21/07/2017 16:21, Thomas Heller via Boost wrote:
Hi list,
After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations...
Thomas, I absolutely agree. Let's make users life easier first, even for those not using CMake. Best, Ion
On 7/21/17 7:21 AM, Thomas Heller via Boost wrote:
Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either;)
Hmm - in looking through the CMake stuff I just came upon this. I'm curious as what it means? The boost library incubator was conceived to support and strengthen the boost review process - not supplant it. Robert Ramey
Am 11.08.2017 10:04 nachm. schrieb "Robert Ramey via Boost" < boost@lists.boost.org>: On 7/21/17 7:21 AM, Thomas Heller via Boost wrote:
Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either;)
Hmm - in looking through the CMake stuff I just came upon this. I'm curious as what it means? The boost library incubator was conceived to support and strengthen the boost review process - not supplant it. I'm saying that even with the incubator, it does not match the ease of just publishing on github and announce your stuff on various channels. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
participants (27)
-
Alain Miniussi -
Andrey Semashev -
Artyom Beilis -
Chris Glover -
Daniela Engert -
David Stone -
degski -
Florent Castelli -
Gavin Lambert -
Groke, Paul -
Ion Gaztañaga -
Joseph Van Riper -
Jürgen Hunold -
Mateusz Loskot -
Mike Gresens -
Nicolas Cornu -
Norbert Wenzel -
paul -
Peter Dimov -
Robert Ramey -
Roger Leigh -
Stefan Seefeld -
Steven Watanabe -
Thomas Heller -
Tim Blechmann -
Vinnie Falco -
Zach Laine