CMake Announcement from Boost Steering Committee
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb@boost.org
On Tue, Jul 18, 2017 at 7:12 AM, Jon Kalb via Boost <boost@lists.boost.org> wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Once upon a time I came to find Boost not for its libraries but for its build system. Since that time I've worked hard to improve all aspects of the build system, the development infrastructure, and at some times touching every Boost library with patches. Hence it saddens me that this is the direction the Committee wants to move in. As you can imagine this decision considerably diminishes my interest in Boost. But such is life :-) As a consequence.. I herby resign from all my duties in the Boost community effectively immediately. This means that I will no longer be in the Release Team. I will no longer manage the CI build infrastructure. I will no longer be the Testing Manager. I will no longer manager the testing infrastructure. As for the various Boost related libraries and tools I've authored or contribute to: * I will continue to maintain Predef. But will be forking it into a non-Boost form moving forward (in similar vein to ASIO). * I will *not* continue to maintain B2 in the Boost form. I will be rewriting b2 into a new form to address the needs of building software that matches the industry I work in. I will be doing this immediately. * I will not be maintaining the testing scripts and tools. Instead I will be focusing on the set of test reporting infrastructure that I haven't had time to get back to as my free time has up to now been devoted to Boost infrastructure improvements. In general I will be continuing to do what I do.. Just not be doing in the Boost community. Many thanks for the many wonderful individuals of the Boost community over more than a decade of my involvement. Goodby.. Adios. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Tue, Jul 18, 2017 at 7:15 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:
Goodby.. Adios.
I am truly sorry to hear that. I have always admired your tireless efforts in an area that most might not consider glamorous and yet is fundamental and needed for every Boost library. I appreciate the work that you've done and I hope all your future projects are successful and rewarding. Regards
On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
As a consequence.. I herby resign from all my duties in the Boost community effectively immediately. This means that I will no longer be in the Release Team.
Since none of the current Boost Steering Committee members are owners in the Github Boost.ORG organization.. Could one of the github owners please change my role from "owner" to "member"? (github doesn't allow you to do that to yourself). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done.
The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem.
For the Boost Steering Committee,
Jon Kalb, Chair
jonkalb@boost.org
Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
Good question! I find the message from a long time member like Rene quite disturbing, to say the least. We evaluated CMake in my company, but decided against it because it doesn't have support for precompiled headers. kind regards Thorsten
Am 18.07.2017 um 17:14 schrieb Thorsten Ottosen via Boost:
Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
Good question!
I find the message from a long time member like Rene quite disturbing, to say the least.
We evaluated CMake in my company, but decided against it because it doesn't have support for precompiled headers.
Have you tried "Cotire" as suggested here as accepted answer: https://stackoverflow.com/questions/148570/using-pre-compiled-headers-with-c... I once tried it several years ago and it seemed to work. However, pre-compiled headers did not really help us at that time. Best regards, Deniz
kind regards
Thorsten
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Den 18-07-2017 kl. 17:14 skrev Thorsten Ottosen via Boost:
Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
Good question!
I find the message from a long time member like Rene quite disturbing, to say the least.
In case it wasn't clear, it's not what Rene says that is disturbing, but that it has come so far that he has to say it. Where is all the discussion that led to this decision? The pros and cons? The feedback from the community and members? kind regards Thorsten
Boost - Dev mailing list wrote
Den 18-07-2017 kl. 17:14 skrev Thorsten Ottosen via Boost:
Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
Good question!
I find the message from a long time member like Rene quite disturbing, to say the least.
In case it wasn't clear, it's not what Rene says that is disturbing, but that it has come so far that he has to say it.
Where is all the discussion that led to this decision? The pros and cons? The feedback from the community and members?
kind regards
There was a lot of discussion on the list recently about various levels of integrations between Boost and CMake. A lot of interest was generated and we thought it was very positive. The intent of the message we sent was to make it clear that there was an intent to actually make something out of these proposals, not to just let them die like some previous CMake efforts have. Please notice that the message does not impose any "way of getting there", nor does it talk about technical superiority of one solution over the other. The problems we believe Boost needs to solve are (1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here) (2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know. I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
Boost - Dev mailing list wrote
Den 18-07-2017 kl. 17:14 skrev Thorsten Ottosen via Boost:
Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
Good question!
I find the message from a long time member like Rene quite disturbing, to say the least.
In case it wasn't clear, it's not what Rene says that is disturbing, but that it has come so far that he has to say it.
Where is all the discussion that led to this decision? The pros and cons? The feedback from the community and members?
kind regards
There was a lot of discussion on the list recently about various levels of integrations between Boost and CMake. A lot of interest was generated and we thought it was very positive. The intent of the message we sent was to make it clear that there was an intent to actually make something out of these proposals, not to just let them die like some previous CMake efforts have.
Please notice that the message does not impose any "way of getting there", nor does it talk about technical superiority of one solution over the other. The problems we believe Boost needs to solve are
(1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here) (2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build, I see such a decision to give up Boost Build entirely for CMake, before we even know if we can actually duplicate all the functionality which Boost Build provides in CMake, as a bad decision. I am not against providing CMake for the user community at large, but I just don't think we should be throwing Boost Build away.
Louis
-- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.
When you originally write: "Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike." it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped. I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ). Unless CMake can be made to duplicate some of this functionality Boost will be offering end-users less functionality than they presently have. I think the goal is always to offer equal or better functionality. I do understand that C++ developers find it easier to understand and use CMake than Boost Build so I think that any proposed move to CMake as the required build environment must take these things into account, and equivalent CMake functionality should be developed to ease the transition. That is why it is important to me that Boost Build be offered as an immediate alternative in Boost's future plans.
Louis
-- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, 2017-07-18 at 22:03 -0400, Edward Diener via Boost wrote:
On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.
When you originally write:
"Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike."
it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped.
I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ).
CMake can handle mutlitple variants, it just requires seperate build trees. However, there are things which cmake can handle that boost build cannot. Boost.Build cannot get find prebuilt libraries or get usage requirements for prebuilt libraries directly, and thus has no mechanism to tell it where the depedencies are. Actually, trying to support multiple variants and prebuilt libraries complicates things. Which is why cmake doesn't support mutliple variants in the same build tree well, and boost build doesn't support prebuilt libraries that well. Of course, there is always workarounds. In bjam, you just create a custom variable to where the prebuilt binary is, and the user needs to pass that in for every dependency. In cmake, you just create multiple build directories for each variant you have. However, the workaround for cmake can be automated across many different libraries, but the workaround for boost.build cannot, as the custom variables could always be different.
On 7/19/2017 10:29 AM, paul via Boost wrote:
On Tue, 2017-07-18 at 22:03 -0400, Edward Diener via Boost wrote:
On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.
When you originally write:
"Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike."
it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped.
I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ).
CMake can handle mutlitple variants, it just requires seperate build trees. However, there are things which cmake can handle that boost build cannot. Boost.Build cannot get find prebuilt libraries or get usage requirements for prebuilt libraries directly, and thus has no mechanism to tell it where the depedencies are.
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
Actually, trying to support multiple variants and prebuilt libraries complicates things. Which is why cmake doesn't support mutliple variants in the same build tree well, and boost build doesn't support prebuilt libraries that well. Of course, there is always workarounds. In bjam, you just create a custom variable to where the prebuilt binary is, and the user needs to pass that in for every dependency. In cmake, you just create multiple build directories for each variant you have. However, the workaround for cmake can be automated across many different libraries, but the workaround for boost.build cannot, as the custom variables could always be different.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:
On 7/19/2017 10:29 AM, paul via Boost wrote:
On Tue, 2017-07-18 at 22:03 -0400, Edward Diener via Boost wrote:
On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:
On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:
I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.
Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.
When you originally write:
"Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike."
it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped.
I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ).
CMake can handle mutlitple variants, it just requires seperate build trees. However, there are things which cmake can handle that boost build cannot. Boost.Build cannot get find prebuilt libraries or get usage requirements for prebuilt libraries directly, and thus has no mechanism to tell it where the depedencies are.
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory. That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one. That is just one issue, the other issue is that it doesn't provide usage requirements for prebuilt libraries. I install a library with Boost.Build, but even even if downstream libraries are using Boost.Build, there is no information available about the its usage requirements. And of course, all this could be added to Boost.Build, but it would run into the same complexities cmake would if it were to add support for multiple variants within the same build tree.
Den 19-07-2017 kl. 18:58 skrev paul via Boost:
On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory.
That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one.
For example, you may say lib SqlApi : : <name>sqlapi <search>$(DEPENDENCY_ROOT)/lib/Debug <variant>debug ; lib SqlApi : : <name>sqlapi <search>$(DEPENDENCY_ROOT)/lib/Release <variant>release ; -Thorsten
AMDG On 07/19/2017 10:58 AM, paul via Boost wrote:
On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory.
b2 library-path=/deps
That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one.
That is just one issue, the other issue is that it doesn't provide usage requirements for prebuilt libraries. I install a library with Boost.Build, but even even if downstream libraries are using Boost.Build, there is no information available about the its usage requirements.
I'm afraid I don't understand. pre-built library targets can have usage requirements just like any other target.
And of course, all this could be added to Boost.Build, but it would run into the same complexities cmake would if it were to add support for multiple variants within the same build tree.
In Christ, Steven Watanabe
On Wed, 2017-07-19 at 11:23 -0600, Steven Watanabe via Boost wrote:
AMDG
On 07/19/2017 10:58 AM, paul via Boost wrote:
On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:
Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.
But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory.
b2 library-path=/deps
I was unaware of this, and Rene was as well. We were discussing adding flags such as --library-<variant>-path.
That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one.
That is just one issue, the other issue is that it doesn't provide usage requirements for prebuilt libraries. I install a library with Boost.Build, but even even if downstream libraries are using Boost.Build, there is no information available about the its usage requirements.
I'm afraid I don't understand. pre-built library targets can have usage requirements just like any other target.
But where does it get those usage requirements from? It should come from the original install. When I install boost(with b2 install or apt-get install), I see no files with bjam targets I can use.
I'm afraid I don't understand. pre-built library targets can have usage requirements just like any other target. But where does it get those usage requirements from? It should come from the original install. When I install boost(with b2 install or apt-get install), I see no files with bjam targets I can use. use-project : boost : /where/ever/boost/is ;
lib foo : foo.cpp : <library>/boost//system ; And that will also build your dependency.
On 18/07/2017 21:28, Edward Diener via Boost wrote:
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build, I see such a decision to give up Boost Build entirely for CMake, before we even know if we can actually duplicate all the functionality which Boost Build provides in CMake, as a bad decision.
+1. I think the first step is to make Boost buildable with CMake while maintaining Boost.Build. After we have enough experience, we can decide to maintain both or drop one of them. Ion
Den 18-07-2017 kl. 23:23 skrev Ion Gaztañaga via Boost:
On 18/07/2017 21:28, Edward Diener via Boost wrote:
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build,
I can take no credit for developing or maintaining Boost.Build. I'm just a user of it. -T
On 7/19/2017 5:08 AM, Thorsten Ottosen via Boost wrote:
Den 18-07-2017 kl. 23:23 skrev Ion Gaztañaga via Boost:
On 18/07/2017 21:28, Edward Diener via Boost wrote:
In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build,
I can take no credit for developing or maintaining Boost.Build. I'm just a user of it.
I meant Vladimir Prus and mentioned your name instead. My mistake.
-T
On 18/07/2017 20:08, Louis Dionne via Boost wrote:
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library. Ion
On 7/18/17 2:18 PM, Ion Gaztañaga via Boost wrote:
On 18/07/2017 20:08, Louis Dionne via Boost wrote:
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library.
LOL - as such a programmer I can tell you you're wrong! I don't think you can make a working Jamfile by cutting and pasting. I have to go back to the bjam documentation and then almost always post a question on the list. Bjam may have it's advantages - but simplicity, transparency and ease of use are not among them.
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Jul 19, 2017 12:00 AM, "Robert Ramey via Boost" <boost@lists.boost.org> wrote:
On 7/18/17 2:18 PM, Ion Gaztañaga via Boost wrote:
On 18/07/2017 20:08, Louis Dionne via Boost wrote:
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library.
LOL - as such a programmer I can tell you you're wrong! I don't think you can make a working Jamfile by cutting and pasting. I have to go back to the bjam documentation and then almost always post a question on the list. Bjam may have it's advantages - but simplicity, transparency and ease of use are not among them.
I'm just a GSoC student, so I don't really fit the "Boost library developer" profile... Anyway, I had to use either CMake or Boost.Build to build and run some tests, and because I had no experience with either, and Boost.Build seemed more boost'y, I went for it. So I've just had an experience learning to write Jamfiles, and I'd argue that it's not that difficult, for a _basic_ case. I.e. as long as you don't need to your own target types and generators, you're fine. It all goes wrong when you need more "advanced" stuff. I think it's cost me approximately 30 hours in total of browsing through docs and source code before I've begun to understand how things work. I still don't understand the pro topics though. It seems to me like there's just not enough documentation/examples. And I understand that it's terribly boring for advanced users to write the docs because this stuff is obvious for them, and impossible for newcomers because they don't understand it themselves. But, I guess, it's a quite common situation. And, as usually, the efforts should be combined, i.e. someone tries to learn Boost.Build, writes down all his questions while gurus help him find and write down the answers. And we obtain nice docs in the end. I'd even be willing to volunteer for the padawan's position (after GSoC though). The point I'm trying to make here is that some non-radical changes might be enough to solve the problems Louis has outlined (second one at the very least, and as some people have indicated CMake might not help with the first one either). And trying them out will probably take much less time than the transition to CMake, so why not try the fast & easy path first? Tom
On 7/18/17 3:52 PM, Tom Westerhout via Boost wrote:
On Jul 19, 2017 12:00 AM, "Robert Ramey via Boost" <boost@lists.boost.org> wrote:
On 7/18/17 2:18 PM, Ion Gaztañaga via Boost wrote:
On 18/07/2017 20:08, Louis Dionne via Boost wrote:
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library.
LOL - as such a programmer I can tell you you're wrong! I don't think you can make a working Jamfile by cutting and pasting. I have to go back to the bjam documentation and then almost always post a question on the list. Bjam may have it's advantages - but simplicity, transparency and ease of use are not among them.
I'm just a GSoC student, so I don't really fit the "Boost library developer" profile... Anyway, I had to use either CMake or Boost.Build to build and run some tests, and because I had no experience with either, and Boost.Build seemed more boost'y, I went for it. So I've just had an experience learning to write Jamfiles, and I'd argue that it's not that difficult, for a _basic_ case. I.e. as long as you don't need to your own target types and generators, you're fine.
It all goes wrong when you need more "advanced" stuff. I think it's cost me approximately 30 hours in total of browsing through docs and source code before I've begun to understand how things work. I still don't understand the pro topics though.
It seems to me like there's just not enough documentation/examples. And I understand that it's terribly boring for advanced users to write the docs because this stuff is obvious for them, and impossible for newcomers because they don't understand it themselves. But, I guess, it's a quite common situation. And, as usually, the efforts should be combined, i.e. someone tries to learn Boost.Build, writes down all his questions while gurus help him find and write down the answers. And we obtain nice docs in the end. I'd even be willing to volunteer for the padawan's position (after GSoC though).
The point I'm trying to make here is that some non-radical changes might be enough to solve the problems Louis has outlined (second one at the very least, and as some people have indicated CMake might not help with the first one either). And trying them out will probably take much less time than the transition to CMake, so why not try the fast & easy path first?
I pretty much agree with this assessment. It starts out simple, but then you need to make something a little bit fancier and then .... I think bjam could be made much better with relatively few changes. The documents are actually quite good. I know this as I had to plow through them for the Nth time the other day. A large part of the problem is that there is too much implicit behavior to actually documentation which is fine when things "just work" but then - .... I and others have been complaining about this for many years. No action has been taken. Maybe it's not doable, or maybe it's a thankless task which is not exceeding tedious for the people who are actually capable of addressing this. I don't know. But now we've come to this. Hopefully we can slog through this without getting lost in the weeds - we'll see. Robert Ramey
On 18/07/2017 20:08, Louis Dionne via Boost wrote:
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library. As long as it's very basic stuff, with no external dependencies, maybe, but that is true of any build system. And if it's not, you need to read a yet to be written documentation (I have heard of urban legends about
On 18/07/2017 23:18, Ion Gaztañaga via Boost wrote: people finding bjam documentation, or is it b2 ? and is it the same as the one embedded with boost ?). And then, sometime, it hang. Bjam is the only build system I got hanging, and the only support I could get from the bjam community could be summarized as "well, that's sad..." and "well, it works on my box, so who care... maybe Intel could modify their tools to accommodate?". I agree with the copy-pasting though, without that you might forget a space somewhere, and the thing is space sensitive (and just because we got used to it does not mean it's normal). Even if there was learning material, one should not have to learn a new boost specific build system just to contribute. And I don't think bjam can build anything else than a simple C++ project so it's not like you can capitalize on the time spent (I tried, then switched to CMake). CMake could be a piece of junk, but it's a maintained, somehow documented, community supported piece of junk, that I can use on real projects. If bjam was so great, it would be used by now. So, now, about that doc generation thing... Alain
On Tue, Jul 18, 2017 at 5:59 PM Alain Miniussi via Boost < boost@lists.boost.org> wrote:
On 18/07/2017 23:18, Ion Gaztañaga via Boost wrote:
On 18/07/2017 20:08, Louis Dionne via Boost wrote:
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library. ...
Even if there was learning material, one should not have to learn a new
boost specific build system just to contribute. And I don't think bjam can build anything else than a simple C++ project so it's not like you can capitalize on the time spent (I tried, then switched to CMake).
CMake could be a piece of junk, but it's a maintained, somehow documented, community supported piece of junk, that I can use on real projects.
I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already. Even IDEs such as CLion and Visual Studio are putting their weight behind it. I am hugely appreciative of anyone who is willing to put aside their own solutions in order to improve interoperability and simplicity. This will surely be a positive thing for Boost and C++ in the long term.
On 19/07/2017 3:48, John McFarlane via Boost wrote:
I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system. This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software. I don't want to waste my time recreating MSVC projects every time I build. I want regression tests to continue working nicely and portable passing common useful options that work in every system. CMake is popular, no doubt. So is autotools, and no one is proposing it for Boost. I have no problems to switch to CMake if: - Cmake does everything Boost.Build does with the same or less work. - Cmake performance is equal or better. CMake popularity is not important for me as a Boost programmer, in some years CMake will be replaced by another super-popular build system. For users we can automatically generate CMake projects from Boost.Build, and maybe other popular build systems. Ion
2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost <boost@lists.boost.org>:
On 19/07/2017 3:48, John McFarlane via Boost wrote:
I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.
This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software.
JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest -- Best Regards, Sergei Nikulov
Am 19.07.2017 um 14:30 schrieb Sergei Nikulov via Boost:
2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost <boost@lists.boost.org>:
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.
That's my understanding, too.
This is unacceptable to me, I want something that really builds the program and also runs tests from the command line
That are pretty much my requirements when switching through a ton of different configurations of compiler versions / bitness (32 or 64) / mode (debug or release) when I test changes to one of the 110 Boost libraries, that I needed to fork.
JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest
Ok, so how do I fire off a libraries test-suite using f.i. msvc-14.1/32/release concurrently to another one using f.i. msvc-14.0/64/release (and may be some more)? I may be missing something. At present I start one process using b2 with these three configuration parameters for each one of the configuration tuples. Something similar happens when I build a Boost distribution. Ciao Dani
2017-07-19 15:47 GMT+03:00 Daniela Engert via Boost <boost@lists.boost.org>:
Am 19.07.2017 um 14:30 schrieb Sergei Nikulov via Boost:
2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost <boost@lists.boost.org>:
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.
That's my understanding, too.
This is unacceptable to me, I want something that really builds the program and also runs tests from the command line
That are pretty much my requirements when switching through a ton of different configurations of compiler versions / bitness (32 or 64) / mode (debug or release) when I test changes to one of the 110 Boost libraries, that I needed to fork.
JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest
Ok, so how do I fire off a libraries test-suite using f.i. msvc-14.1/32/release concurrently to another one using f.i. msvc-14.0/64/release (and may be some more)? I may be missing something.
Yes, you've got me :) This is one of the bad sides about CMake. To cover your case, I usually using buildbot with the different configurations (Debug/Release/etc...) Disclaimer: I'm not from Boost Steering Committee, and not pushing CMake for Boost libraries. Just provide information to Ion how to use cmake from command line :) -- Best Regards, Sergei Nikulov
Sergei Nikulov wrote:
JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest
Well not entirely, because for MS backends you can pick --config Release at build time and for the rest you need to pick -DCMAKE_BUILD_TYPE at configure time. Not to mention the address-model, choosing which MSBuild supports at build time, but CMake not only doesn't, you have to use an entirely different generator for 64 bit.
Am 19.07.2017 3:12 nachm. schrieb "Peter Dimov via Boost" < boost@lists.boost.org>: Sergei Nikulov wrote: JFYI, same commands used on every system
1. generate> cmake .. 2. build> cmake --build . 3. test> ctest
Well not entirely, because for MS backends you can pick --config Release at build time and for the rest you need to pick -DCMAKE_BUILD_TYPE at configure time. Not to mention the address-model, choosing which MSBuild supports at build time, but CMake not only doesn't, you have to use an entirely different generator for 64 bit. What does this mean for boost's regression test? Especially for the fiber library I need a combination of: - address-model (32/64) - architecture (arm, arm64, mips, ....) - binary format (elf, ms, o32, mach-o, ...) - ABI (sysv, aapcs, ...) - implementation (assembler, ucontext, windows fibers) - segmented stacks (on/off) - valgrind (on/off) - transactional memory (on/off) ... Do I need to provide for each combination a different generator?
On Wed, 2017-07-19 at 15:58 +0200, Oliver Kowalke via Boost wrote:
Am 19.07.2017 3:12 nachm. schrieb "Peter Dimov via Boost" < boost@lists.boost.org>:
Sergei Nikulov wrote:
JFYI, same commands used on every system
1. generate> cmake .. 2. build> cmake --build . 3. test> ctest
Well not entirely, because for MS backends you can pick --config Release at build time and for the rest you need to pick -DCMAKE_BUILD_TYPE at configure time.
Not to mention the address-model, choosing which MSBuild supports at build time, but CMake not only doesn't, you have to use an entirely different generator for 64 bit.
What does this mean for boost's regression test? Especially for the fiber library I need a combination of: - address-model (32/64) - architecture (arm, arm64, mips, ....) - binary format (elf, ms, o32, mach-o, ...) - ABI (sysv, aapcs, ...) - implementation (assembler, ucontext, windows fibers) - segmented stacks (on/off) - valgrind (on/off) - transactional memory (on/off) ... Do I need to provide for each combination a different generator?
You can write a ctest script to iterate over each combination for testing. Its just a for loop over each one. Or a cmake script that can be written do it as well. Since its commmon with boost to test over many combinations, contributing a script for boost developers to use would be helpful.
On 2017-07-19 14:58, Oliver Kowalke via Boost wrote:
What does this mean for boost's regression test? Especially for the fiber library I need a combination of: - address-model (32/64) - architecture (arm, arm64, mips, ....) - binary format (elf, ms, o32, mach-o, ...) - ABI (sysv, aapcs, ...) - implementation (assembler, ucontext, windows fibers) - segmented stacks (on/off) - valgrind (on/off) - transactional memory (on/off) ... Do I need to provide for each combination a different generator?
I would suggest that you would start off by dropping these options: - address-model - architecture - binary format They are already handled by standard CMake options to choose the compiler and its compile/link flags, so there's no need to deviate from the common way of doing things. The rest can be implemented straightforwardly as cache options so that you can run cmake with options like -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D…] You would need to make a build directory for each combination you want to test, and then run cmake to configure that combination, then build and test. Regards, Roger
The rest can be implemented straightforwardly as cache options so that you can run cmake with options like
-Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D…]
Firstly, valgrind belongs in ctest, not cmake. Very easy to use there. Secondly, in cmake 3 we try not to configure things using -D as we did in cmake 2. Instead we make targets customised for that build combination. The user then chooses to make or link to those targets if they want those targets. You can, and of course do, select a small subset of the available target graphs as the default. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 19/07/2017 14:30, Sergei Nikulov via Boost wrote:
2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost <boost@lists.boost.org>:
On 19/07/2017 3:48, John McFarlane via Boost wrote:
I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.
This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software.
JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest
Many thanks. I've seen the build option was added in CMake 3.0 a couple of years ago. Good to know, because there are many internet tutorials calling "MsBuild" and "make". Ion
Le 19.07.17 à 14:19, Ion Gaztañaga via Boost a écrit :
On 19/07/2017 3:48, John McFarlane via Boost wrote:
I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.
I personally believe this is in fact an advantage, especially for large projects, because we do not need to recreate the full build project in memory every time we need to build a library/executable. The fact that the build should be faster was discussed in this ML and proposed by Rene for boost.build v3 (if I recall correctly).
This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software. I don't want to waste my time recreating MSVC projects every time I build. I want regression tests to continue working nicely and portable passing common useful options that work in every system.
CMake is popular, no doubt. So is autotools, and no one is proposing it for Boost. I have no problems to switch to CMake if:
- Cmake does everything Boost.Build does with the same or less work. - Cmake performance is equal or better.
CMake popularity is not important for me as a Boost programmer, in some years CMake will be replaced by another super-popular build system. For users we can automatically generate CMake projects from Boost.Build, and maybe other popular build systems.
This statement can be done for anything (including Boost), and you are right, all big names are developing their own build tool (Facebook, Google, etc). So it can be seen as just a matter of time that cmake gets replaced. Today, I would just say "who knows?". This also tells us that this aspect for C++ developers cannot be undermined and, since it cannot be undermined, it deserves more effort. The build system is not the primary focus of boost, so in a sense it is a good thing that this part is outsourced from a huge community. Let's invent a name for that: we should be "full stack C++ developers (c)" (sounds bad I agree). Raffi
On 19/07/2017 3:48, John McFarlane via Boost wrote:
I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.
CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system. A little bit like bootstrap.sh does, plus the project-config.jam that I need to modify by hand each time I want to test a new configuration.
This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software. I don't, I want too use the same system I'm already used to anyway on
I don't want to waste my time recreating MSVC projects every time I build. I want regression tests to continue working nicely and portable passing common useful options that work in every system.
CMake is popular, no doubt. So is autotools, and no one is proposing it for Boost. Because it's not available on Window I guess. On Unix-like, I've found autotools slightly less worse than bjam in the sense that when I need to deal with code mixing MPI, C++, Fortran etc.. bjam is out. So I went autotool->bjam->autotool(yurk!)->CMake. But if a project is simple enough for bjam, then moving to autotool is
On 19/07/2017 14:19, Ion Gaztañaga via Boost wrote: those platforms. probably a bad idea.
I have no problems to switch to CMake if:
- Cmake does everything Boost.Build does with the same or less work. I just enter 'make' in my build directories, cmake is re-called automatically if necessary. And it does a lot of thing I could not do with bjam (arbitrary feature detection mostly, seems a PITA with bjam). And I can switch between all my configurations just by changing the build directory which, when I need to test the cross product of various compilers/MPI, is a huge gain. I am not sure how to build an test N configuration at the same time with bjam without having N instance of the code tree. Maybe it's in the tutorial.
- Cmake performance is equal or better. Well, cmake never required me having to launch a script in the back ground to send signals to hanging bjam tasks during test (eternity can be quite long), so how can it be worse... as for the (usually parallel) build, source dependencies are what they are, and so is the compiler.
CMake popularity is not important for me as a Boost programmer, in some years CMake will be replaced by another super-popular build system.
Yep, and maybe people will choose to move to that system if they think it's worth it.
For users we can automatically generate CMake projects from Boost.Build, and maybe other popular build systems.
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 19/07/2017 14:57, Alain Miniussi via Boost wrote:
I have no problems to switch to CMake if:
- Cmake does everything Boost.Build does with the same or less work. I just enter 'make' in my build directories, cmake is re-called automatically if necessary. And it does a lot of thing I could not do with bjam (arbitrary feature detection mostly, seems a PITA with bjam). And I can switch between all my configurations just by changing the build directory which, when I need to test the cross product of various compilers/MPI, is a huge gain. I am not sure how to build an test N configuration at the same time with bjam without having N instance of the code tree. Maybe it's in the tutorial.
I test my libraries with the following lines in windows: MSVC b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on MINGW b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast. My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)? Best, Ion
On 19/07/2017 14:57, Alain Miniussi via Boost wrote:
I have no problems to switch to CMake if:
- Cmake does everything Boost.Build does with the same or less work. I just enter 'make' in my build directories, cmake is re-called automatically if necessary. And it does a lot of thing I could not do with bjam (arbitrary feature detection mostly, seems a PITA with bjam). And I can switch between all my configurations just by changing the build directory which, when I need to test the cross product of various compilers/MPI, is a huge gain. I am not sure how to build an test N configuration at the same time with bjam without having N instance of the code tree. Maybe it's in the tutorial.
I test my libraries with the following lines in windows:
MSVC
b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on
MINGW
b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on
Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast.
My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)? I do not know what are the performances with bjam, I just create one build tree (outside of the source tree) per variant, configure once for each variant and then iterate over the build directories. I want to keep
On 19/07/2017 16:59, Ion Gaztañaga via Boost wrote: the build trees and I want to launch different variants build/texts on different nodes, so the trees need to be separate anyway. So it does take some space since I do not delete the build tree (that is, I choose to keep the object files, I do not know if your technique does the same). But I want to be able to go into the directory of combination X's build when things go wrong anyway. But my variants includes properties (if that the term used to designate toolset, variant etc..) that are not anticipated be bjam. Each MPI implementation correspond to a specify project-config.jam file (sometime simple, sometime not), so I am not sure how I could iterate over intel-mpi-5.0.1,open-mpi-1.6.2, etc... basically, I need to check how it works with different versions/vendor.configuration of an external tools. Regards Alain
Best,
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Jul 19, 2017 at 5:39 PM, Alain Miniussi via Boost <boost@lists.boost.org> wrote:
MSVC
b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on
MINGW
b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on
Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast.
My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)?
I do not know what are the performances with bjam, I just create one build tree (outside of the source tree) per variant, configure once for each variant and then iterate over the build directories. I want to keep the build trees and I want to launch different variants build/texts on different nodes, so the trees need to be separate anyway. So it does take some space since I do not delete the build tree (that is, I choose to keep the object files, I do not know if your technique does the same). But I want to be able to go into the directory of combination X's build when things go wrong anyway. But my variants includes properties (if that the term used to designate toolset, variant etc..) that are not anticipated be bjam. Each MPI implementation correspond to a specify project-config.jam file (sometime simple, sometime not), so I am not sure how I could iterate over intel-mpi-5.0.1,open-mpi-1.6.2, etc... basically, I need to check how it works with different versions/vendor.configuration of an external tools.
So in addition to cmake we need scripts to create all those build directories and to actually run all those builds? And every project using cmake has to bring their own version of those scripts?
On 19/07/2017 18:03, Olaf van der Spek wrote:
MSVC
b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on
MINGW
b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on
Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast.
My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)? I do not know what are the performances with bjam, I just create one build tree (outside of the source tree) per variant, configure once for each variant and then iterate over the build directories. I want to keep the build trees and I want to launch different variants build/texts on different nodes, so the trees need to be separate anyway. So it does take some space since I do not delete the build tree (that is, I choose to keep the object files, I do not know if your technique does the same). But I want to be able to go into the directory of combination X's build when things go wrong anyway. But my variants includes properties (if that the term used to designate toolset, variant etc..) that are not anticipated be bjam. Each MPI implementation correspond to a specify project-config.jam file (sometime simple, sometime not), so I am not sure how I could iterate over intel-mpi-5.0.1,open-mpi-1.6.2, etc... basically, I need to check how it works with different versions/vendor.configuration of an external tools. So in addition to cmake we need scripts to create all those build
On Wed, Jul 19, 2017 at 5:39 PM, Alain Miniussi via Boost <boost@lists.boost.org> wrote: directories and to actually run all those builds? And every project using cmake has to bring their own version of those scripts? Only if you want to use that technique, which I find convenient (and which I cannot use with bjam, so I need to override the previous build for each configuration, cannot run in parallel on different nodes, unless have one git clone per flavor). Right now, with bjam, those libs (the one requiring such tunning) are basically not tested by default. It's not one per project, it's one. And those script/config are likely to be platform specific, they're would be certainly no much point in sharing the specificities of the platforms I use.
Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?
On the mailing list. A few people are also on the #boost Slack channel, but I think we'd be better discussing exactly what the community should do and how on the ML, since it's easier to follow. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, Jul 18, 2017 at 3:12 PM, Jon Kalb via Boost <boost@lists.boost.org> wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
Isn't it a bit weird to decide this without further input from the community? It also sounds like you're starting with a solution rather than a problem. -- Olaf
On 7/18/17 6:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. With all due respect to the steering committee, I would have felt a lot better about this a) if the solicitations for .. proposals had occurred first b) announcement of intent would be later and be contingent or some sort of consensus on a particular proposal. As it reads - it sounds like a decision has been made to .... what exactly? Robert Ramey
On Tue, Jul 18, 2017 at 11:27 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
As it reads - it sounds like a decision has been made to .... what exactly?
My reading is as follows: * CMake will be a requirement for all libraries * Bjam will be optional I don't presume to speak for the committee, this is my personal interpretation.
On 7/18/17 6:12 AM, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
With all due respect to the steering committee, I would have felt a lot better about this
a) if the solicitations for .. proposals had occurred first
b) announcement of intent would be later and be contingent or some sort of consensus on a particular proposal.
As it reads - it sounds like a decision has been made to .... what exactly?
Robert Ramey
I think I can apologize for the whole SC if this message was perceived as coming "out of the blue", as this was clearly not the intent. Indeed, ideas have been floating around on this list these pasts months and we wanted to make a strong positive statement about our desire to solve the following problems (which I've mentionned in a previous mail): (1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here) (2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know. Furthermore, there was an implicit understanding that if the community as a whole objected to any change or could not come to any consensus, nothing would be forced onto it. However, the _intent_ is clear, and it is that if we do have a good solution for solving problems (1) and (2), we should do it (as opposed to rejecting it, like what has happened in the past). I would love to see the Boost community come together and figure out how we can solve problems (1) and (2) in the best possible way. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Tue, 18 Jul 2017 at 15:00 Louis Dionne via Boost <boost@lists.boost.org> wrote:
(1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here)
(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.
Furthermore, there was an implicit understanding that if the community as a whole objected to any change or could not come to any consensus, nothing would be forced onto it. However, the _intent_ is clear, and it is that if we do have a good solution for solving problems (1) and (2), we should do it (as opposed to rejecting it, like what has happened in the past).
I would love to see the Boost community come together and figure out how we can solve problems (1) and (2) in the best possible way.
Louis
It has been discussed multiple times that supporting (1) does not require switching to CMake. (2) probably does, but from my point of view, that would actually make boost less usable in my work environment. I use CMake for all of my personal and open source projects and it's great for that, but no company I have worked for has used CMake internally for anything. I'm sure that there are companies that do, but in my experience, every big C++ shop maintains their own custom build system so switching to CMake will add a new dependency that didn't previously exist. It's probably not a deal breaker, but it is a regression because every time I upgrade boost, I might need to upgrade CMake, and because we don't rely on system installed packages for anything I would need to upgrade CMake in our internal package manager before I can upgrade boost. Currently, all I need to do it write a script called from our custom build system that does something like; - call bootstrap - call b2 with appropriate flags (this is the hard part) - add the include path - synthesize the link libraries What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that. For me, from a user point of view, I like things they way they currently are. I can build boost easily in a work environment with no dependencies when not using CMake. When I am using CMake, I can easily set BOOST_ROOT and call FindPackage(Boost) and everything just works. I've had very few problems with this. I've never had to deal with boost.build in any significant way, so I can't speak to how difficult it is. But I feel like this keeps coming up because some people really don't like boost.build and are tying to force the change and something the users really want when that's not actually the case when considering the wider audience. -- chris
On Tue, Jul 18, 2017 at 3:24 PM, Chris Glover via Boost < boost@lists.boost.org> wrote: [snip] internal package manager before I can upgrade boost. Currently, all I need
to do it write a script called from our custom build system that does something like;
- call bootstrap - call b2 with appropriate flags (this is the hard part) - add the include path - synthesize the link libraries
What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that.
There is no reason why Boost+CMake can't do that too. Zach
On Tue, Jul 18, 2017 at 3:24 PM, Chris Glover via Boost < boost@lists.boost.org> wrote:
[snip]
internal package manager before I can upgrade boost. Currently, all I need
to do it write a script called from our custom build system that does something like;
- call bootstrap - call b2 with appropriate flags (this is the hard part) - add the include path - synthesize the link libraries
What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that.
There is no reason why Boost+CMake can't do that too. In order for it to be as self-contained as it is now, it would require embedding the source code for CMake and any of its dependencies (I'm not sure whether there any to speak of) into the Boost distribution. I agree with Chris in that a big advantage of the current setup is that it is not dependent on CMake being installed on the user's system already. Even in today's almost-always-connected-to-a-package-manager world,
On 07/18/2017 04:33 PM, Zach Laine via Boost wrote: there are setups where it is cumbersome to say the least to install additional packages (especially binaries) when they are needed. I'm not a fan of Boost.Build either (I've used it almost exclusively in the workflow described above), but it seems like this effort is "discard one poorly documented, difficult to author/read build tool used by relatively few people, adopt a poorly documented, difficult to author/read build tool used by a lot more people". It's a shame that there really isn't a better tool that is easy to read, write, extend, and use across multiple platforms. At the risk of running into the situation described in https://xkcd.com/927/, I hope something better than CMake emerges someday. Jason
On 19/07/2017 08:24, Chris Glover wrote:
I use CMake for all of my personal and open source projects and it's great for that, but no company I have worked for has used CMake internally for anything. I'm sure that there are companies that do, but in my experience, every big C++ shop maintains their own custom build system so switching to CMake will add a new dependency that didn't previously exist. It's probably not a deal breaker, but it is a regression because every time I upgrade boost, I might need to upgrade CMake, and because we don't rely on system installed packages for anything I would need to upgrade CMake in our internal package manager before I can upgrade boost.
Possibly I'm in the minority (although I do work for a C++ company) but I can confirm that we don't use CMake for anything. (I have encountered it exactly once in an open source project [out of many others that don't use it] and found it confusing and frustrating to use, much more so than B2. But this is from the perspective of making it build existing code, not from the perspective of writing build scripts for it, so YMMV.) I can't speak to the technical merits of either (especially not writing build scripts) but I can say that I don't find the current incarnation of B2 hard to use, once you figure out the appropriate collection of flags to use (which is reasonably well documented, but as always could be better).
What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that.
Agreed. I don't even know how you get cmake on Windows, but it seems like it would be annoying to maintain that separately. (And then deal with possible conflicts between certain Boost versions needing specific cmake versions.) At the end of the day, as a user of Boost, I don't really care what it uses as long as it Just Works™. But this announcement seems a little like putting the cart before the horse.
On Tue, Jul 18, 2017 at 4:12 PM, Jon Kalb via Boost <boost@lists.boost.org> wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Thank You! Finally we will have documented, maintained, human readable and feature rich build system! It is so good as I have numerous issues lagging in tickets bug reports for Boost.Locale that it is almost impossible to fix due to total lack of support of basic stuff like built in libraries dependencies search/configuration. Once Again Thank You. Artyom Beilis
On 18 July 2017 at 21:54, Artyom Beilis via Boost <boost@lists.boost.org> wrote:
On Tue, Jul 18, 2017 at 4:12 PM, Jon Kalb via Boost <boost@lists.boost.org> wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
Thank You!
Finally we will have documented, maintained, human readable and feature rich build system! It is so good as I have numerous issues lagging in tickets bug reports for Boost.Locale that it is almost impossible to fix due to total lack of support of basic stuff like built in libraries dependencies search/configuration.
Once Again Thank You.
I second Artyom's. There are numerous issues dangling around Boost.GIL related to IO, and build configuration that can easily pick up user-installed zlib, libpng, libjpeg is on demand. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Tue, 2017-07-18 at 06:12 -0700, Jon Kalb via Boost wrote:
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
Ultimately, we want to support both use cases for cmake: * Prebuilt libraries through `find_package` * Integrated builds through `add_subdirectroy` I have setup an initial build of cmake that supports this. Of course, there is more work to be done. To make these changes, I setup scripts that can be used to generate cmake from mustache templates. This will make it easier to experiment with different cmake designs as we move forward: https://github.com/pfultz2/boost-cmake I mainly was following Daniel Pfeifer's Effective CMake, which is why the template directory is called effective. However, I am working on some modules to help generate configuration and to help provide some of the other missing pieces from boost.build. It can also help reduce the repitition. I would like to explore this option more as well with community feedback.
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end. However, I can't call this decision process anything but broken. Since its founding, Boost was run by open discussions on a mailing list. There were people whose opinion carried a lot of weight, but that was because they wrote a lot of high-quality code and expressed themselves clearly and openly. Today, we have Boost Steering Committee, whose members are elected not by developers or users of Boost through an open process, but through a closed process at a conference somewhere. There is no doubt that all SC members mean only good for Boost and C++ community, I know many of them as excellent developers who contributed a lot to Boost. However, other members of SC are not involved much, and some, including committee chair, do not seem to even have commit access to Boost. Again, I'm sure everybody meant only best, but something went wrong. Specifically, a committee that is not elected by Boost community and has members who never contributed any code met somewhere and made a vague decision that was poorly communicated and immediately cost the project a person who actually did a ton of work. I'm sure that a group elected by and from active developers would have done better at all fronts. I think that for future of Boost, it would be better if the Steering Committee immediately resign, and have an open election process for its replacement. Personally, I'll be happy to vote for many current members, but I feel that a governance based on open process will be better in the long run. Thanks, Volodya
On 18.07.2017 17:00, Vladimir Prus via Boost wrote:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.
Exactly ! A decision such as this one will affect project developers and maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee". To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole. It's not only entirely against the spirit of Free Software and Open Source, but it's also impossible to implement. Who will be responsible for the change ? Who will be responsible for any fallout generated in the process (and one has to be very naive to assume that there won't be any) ? So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 18.07.2017 17:00, Vladimir Prus via Boost wrote:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.
Exactly ! A decision such as this one will affect project developers and maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee".
Let me please quote the original message: We are soliciting comments and proposals from the community to guide the process and the goals. Basically, what we're saying is not "we're doing this, now implement it". It's more like "we've got some problems, let's figure how to fix them together".
To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole.
To be clear, things will be imposed on people in any decently-sized organization. For example, it was imposed on me to add Boost.Build support when Hana was accepted into Boost, and I conformed.
[...]
So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed.
Please note that the original announcement does not preclude this from happening; so long as new authors can stick to CMake and users can integrate with Boost seamlessly from CMake, I do think this would be a valid way to solve the problem. I'm assuming that there would be a way to generate CMake config files that work out of the box from B2 with your approach. It does add complexity to the system, but that's a solution like another, and in fact it does have its advantages too since it means we don't need a wholesale migration when CMake is not cool anymore. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 18.07.2017 19:43, Louis Dionne via Boost wrote:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end. Exactly ! A decision such as this one will affect project developers and
On 18.07.2017 17:00, Vladimir Prus via Boost wrote: maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee". Let me please quote the original message:
We are soliciting comments and proposals from the community to guide the process and the goals.
Basically, what we're saying is not "we're doing this, now implement it". It's more like "we've got some problems, let's figure how to fix them together".
While I agree that sounds much better, it is not my reading of the original. "...announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike..." is a statement of a (perceived) solution, not a problem statement combined with an invitation to think about possible solutions.
To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole. To be clear, things will be imposed on people in any decently-sized organization. For example, it was imposed on me to add Boost.Build support when Hana was accepted into Boost, and I conformed.
Yeah, when you submit a library to Boost, you know exactly what you get yourself into. The current situation is quite different, though. (And for avoidance of doubt: I don't really want to talk about the technical details of the change, whether cmake really is the best choice, or how hard it would be for me to learn. As Vladimir has said in another reply: it's the process itself that is utterly broken, as those who are concerned the most aren't even consulted, at least not in the decision-making process.)
[...]
So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed. Please note that the original announcement does not preclude this from happening; It does.
so long as new authors can stick to CMake and users can integrate with Boost seamlessly from CMake, I do think this would be a valid way to solve the problem. But that's not at all what I'm saying. My point is precisely that I (as Boost.Python maintainer) do not want others to request from me that Boost.Python be buildable using cmake, and then submit bug reports about a broken cmake infrastructure that I'm neither able nor willing to maintain. What I do suggest is that I provide a (reasonably simple) way to build Boost.Python (using infrastructure I understand and thus can maintain), with integration points so the Boost super-project can be built with Boost.Python being part of it.
I'm assuming that there would be a way to generate CMake config files that work out of the box from B2 with your approach.
I think that is very naive. Of course, others are free to use their own wrapper tools, but I feel in no way obliged to support those.
It does add complexity to the system, but that's a solution like another, and in fact it does have its advantages too since it means we don't need a wholesale migration when CMake is not cool anymore.
Yes. I have repeatedly pointed out another (much more natural) solution for the problem of wholesale migrations (modularity !), which unfortunately didn't receive the required support to be considered seriously. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Yes. I have repeatedly pointed out another (much more natural) solution for the problem of wholesale migrations (modularity !), which unfortunately didn't receive the required support to be considered seriously.
Please have a look at my second proposal at [1] and let me know what you think (on that thread if possible). I suggest we all start working together on a solution and see what good can come out of it. Louis [1]: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp46... -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 19/07/2017 11:43, Stefan Seefeld wrote:
So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed.
Doesn't this just then push the burden onto the user of Boost libraries to have *all* of B2, cmake, autotools, scons, rake, ant, vanilla make (possibly with GNU extensions), etc etc ad infinitum? I don't see how that could ever be practical.
On 7/18/17 5:06 PM, Gavin Lambert via Boost wrote:
Doesn't this just then push the burden onto the user of Boost libraries to have *all* of B2, cmake, autotools, scons, rake, ant, vanilla make (possibly with GNU extensions), etc etc ad infinitum? I don't see how that could ever be practical.
One thing that always seems to get lost in this discussion is the distinction between library developers and library users. Library users need a simple way to import libraries. If one where to make (or if it already exists) most library users would be satisfied if all that had to do was something like FindBoostSerializaton or something like that. Since they are downloading binaries, they wouldn't care how boost was built etc. Robert Ramey
On 19/07/2017 14:41, Robert Ramey wrote:
One thing that always seems to get lost in this discussion is the distinction between library developers and library users. Library users need a simple way to import libraries. If one where to make (or if it already exists) most library users would be satisfied if all that had to do was something like FindBoostSerializaton or something like that. Since they are downloading binaries, they wouldn't care how boost was built etc.
That doesn't necessarily follow. From that perspective, there's two kinds of Boost library users (ignoring those who want to actually modify Boost code): 1. The kind that just downloads prebuilt binaries and wants to use them. This group could be amply served by providing a pkgconfig file for Linux and a props file for Windows+VS -- though since ultimately in both cases it's mostly just specifying where the files were put (which could be different for each user) this is probably more of a documentation thing (providing a template where they fill in the actual path themselves) than anything else. I suspect the Linux distribution package maintainers probably already do this sort of thing; if you want to use system-provided Boost then it Just Works™. 2. The kind that wants to build the libraries themselves. There's many reasons for this; some want to use them on compilers or environments for which prebuilt binaries are not available; some want to tweak the settings for some particular library; some just want confidence that they have the actual source for the binary. These people mostly just want a simple command to build everything (or whatever subset they require). For the most part, they don't care how it happens or what tool is used, but the fewer external dependencies the better (as fewer things to go wrong). I've made some assumptions, of course, but I believe this is true.
On 7/18/17 11:57 PM, Gavin Lambert via Boost wrote:
On 19/07/2017 14:41, Robert Ramey wrote:
One thing that always seems to get lost in this discussion is the distinction between library developers and library users. Library users need a simple way to import libraries. If one where to make (or if it already exists) most library users would be satisfied if all that had to do was something like FindBoostSerializaton or something like that. Since they are downloading binaries, they wouldn't care how boost was built etc.
That doesn't necessarily follow.
From that perspective, there's two kinds of Boost library users (ignoring those who want to actually modify Boost code):
1. The kind that just downloads prebuilt binaries and wants to use them.
This group could be amply served by providing a pkgconfig file for Linux and a props file for Windows+VS -- though since ultimately in both cases it's mostly just specifying where the files were put (which could be different for each user) this is probably more of a documentation thing (providing a template where they fill in the actual path themselves) than anything else. I suspect the Linux distribution package maintainers probably already do this sort of thing; if you want to use system-provided Boost then it Just Works™.
2. The kind that wants to build the libraries themselves.
There's many reasons for this; some want to use them on compilers or environments for which prebuilt binaries are not available; some want to tweak the settings for some particular library; some just want confidence that they have the actual source for the binary. These people mostly just want a simple command to build everything (or whatever subset they require). For the most part, they don't care how it happens or what tool is used, but the fewer external dependencies the better (as fewer things to go wrong).
I've made some assumptions, of course, but I believe this is true.
FWIW - in 15 years, getting feedback from users - mostly bugs or confusions about the library, I have never once found anyone who has actually run the tests for the serialization library on their own system. The only testing, other than my own, that I have been able to discern has been on the boost testing matrix. Also note that I have included CMake files for building and testing the serialization library for several years and I have never received any feedback on this. This leads me to conclude one of the following a) the CMake version of the build test is absolutly correct and the library tests always pass so there is nothing ever to report. b) No one has ever used these CMake files. You decide.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/18/2017 7:43 PM, Stefan Seefeld via Boost wrote:
On 18.07.2017 17:00, Vladimir Prus via Boost wrote:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.
Exactly ! A decision such as this one will affect project developers and maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee".
To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole. It's not only entirely against the spirit of Free Software and Open Source, but it's also impossible to implement. Who will be responsible for the change ? Who will be responsible for any fallout generated in the process (and one has to be very naive to assume that there won't be any) ?
So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed.
In the current monolithic structure of Boost, with some 130+ libraries being involved, it would lead to quite a problem for end-users if each library just did their own thing as regards how a library is built, tested, and documented.
Stefan
There is no doubt that all SC members mean only good for Boost and C++ community, I know many of them as excellent developers who contributed a lot to Boost. However, other members of SC are not involved much, and some, including committee chair, do not seem to even have commit access to Boost. Again, I'm sure everybody meant only best, but something went wrong.
I've been keeping out of this thread and will continue to do so given my past history on this topic, but I had to say something in response to this above. The Boost steering committee chair is, bar none, one of the great pillars and foundation stones of the C++ community rivaling, perhaps surpassing, Bjarne himself in terms of sustained and deep contribution to the C++ ecosystem over such a long period. He has given of himself, repeatedly, in such quantity and without fanfare nor publicity in such a multitude of areas, that I find the request for him to resign beyond consideration. He has helped me personally with Boost GSoC over multiple years, found *tens* of thousands of dollars of needed funding when needed, he has gone out of his way to facilitate students and bring new blood into C++ and Boost, organised two of the major global C++ conferences for however many years, and he is such a nice guy in general. I may not always agree with Jon, but by God do I respect him and his judgements. I'm sorry, but calling for him to resign is **unacceptable**. Period. (and for your information, Jon does not have commit access to Boost **by choice** for various reasons not important to this thread. Not for any other reason, certainly nothing to do with lack of service to Boost) Niall
On 19/07/2017 03:01, Niall Douglas via Boost wrote:
There is no doubt that all SC members mean only good for Boost and C++ community, I know many of them as excellent developers who contributed a lot to Boost. However, other members of SC are not involved much, and some, including committee chair, do not seem to even have commit access to Boost. Again, I'm sure everybody meant only best, but something went wrong.
(and for your information, Jon does not have commit access to Boost **by choice** for various reasons not important to this thread. Not for any other reason, certainly nothing to do with lack of service to Boost)
I am sure everybody has good reasons, but of 9 members of SC, I can only find 4 in the list of GitHub project members, specifically Hartmut Kaiser, Louise Dionne, Michael Caisse and Sebastian Redl. I could not find 5 others. It is theoretically possible that I just did not recognize one of the people who do not use full name on GitHub, and it would be great if the Steering Committee either confirm or correct my numbers. However, if the numbers are accurate, it means that significant part of the SC, in fact majority, are not contributors to the project they intend to steer. That is very non-typical in volunteer open-source projects, and frankly I don't see why would an active developer take direction from such as committee or how such committee can make decisions on important matters. Build system question is not trivial, but it can be settled by a sufficiently motivated group of developers just doing a lot of work. There are other questions looming for a while that would require wide agreement, and it would be great for the future of Boost if those who write the code take matters in their hands, and not rely on committee of (mostly) by-standers to make a closed-door decision. Thanks, Volodya
Den 19-07-2017 kl. 08:49 skrev Vladimir Prus via Boost:
On 19/07/2017 03:01, Niall Douglas via Boost wrote:
However, if the numbers are accurate, it means that significant part of the SC, in fact majority, are not contributors to the project they intend to steer. That is very non-typical in volunteer open-source projects, and frankly I don't see why would an active developer take direction from such as committee or how such committee can make decisions on important matters.
Vladimir has a point. The communication from the SC is this announcement is horrible. I have never seen a mail like Rene's on this list before. Who is replacing Rene? Someone from the SC? -T
On Tue, Jul 18, 2017 at 5:00 PM, Vladimir Prus via Boost < boost@lists.boost.org> wrote:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our
desire and intent to move Boost’s build system to CMake for users and developers alike.
I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.
However, I can't call this decision process anything but broken.
Since its founding, Boost was run by open discussions on a mailing list.
Yes, and this is as true today as it was before. Before the steering committee even looked at the CMake issue, there was a large mailing list discussion on moving to CMake. That discussion was started with the express intent to bring a proposal to the steering committee. None of this should be a surprise. Boost needs a steering committee to break stalemates and that is why it was created and exists today. The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats. Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission. Enough is enough. "Finally" is the word I keep seeing over and over on the reddit discussion. There were people whose opinion carried a lot of weight, but that was
because they wrote a lot of high-quality code and expressed themselves clearly and openly. Today, we have Boost Steering Committee, whose members are elected not by developers or users of Boost through an open process, but through a closed process at a conference somewhere.
There is no doubt that all SC members mean only good for Boost and C++ community, I know many of them as excellent developers who contributed a lot to Boost. However, other members of SC are not involved much, and some, including committee chair, do not seem to even have commit access to Boost. Again, I'm sure everybody meant only best, but something went wrong.
Specifically, a committee that is not elected by Boost community and has members who never contributed any code met somewhere and made a vague decision that was poorly communicated and immediately cost the project a person who actually did a ton of work. I'm sure that a group elected by and from active developers would have done better at all fronts.
The steering committee was created to protect the mission of Boost. It is comprised of Boost developers, users, and leaders in the C++ community. Everyone on that committee is looking out for the best interests of Boost and is well qualified to do so. The decision to move to CMake was made unanimously.
I think that for future of Boost, it would be better if the Steering Committee immediately resign, and have an open election process for its replacement. Personally, I'll be happy to vote for many current members, but I feel that a governance based on open process will be better in the long run.
The steering committee is set up like many others in the Open Source world. People are chosen for various reasons but primary among them is their commitment to Boost's mission and doing what is right for Boost. This is how the founders set it up and how Boost ever switched to git. I'm sorry you and a couple others aren't happy with the decision made, but any decision in a deadlock situation is bound to disappoint someone. -- David Sankel
I hate getting into these kinds of arguments.. But this email is a bit too far for me to not respond. On Wed, Jul 19, 2017 at 6:05 AM, David Sankel via Boost < boost@lists.boost.org> wrote:
Boost needs a steering committee to break stalemates and that is why it was created and exists today.
There was no stalemate. Almost every time cmake has been brought up there's been a discussion as to the merits of the build system and the impact on switching. Until now the SC never got involved.
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
No. There where never any threats. Only statements of what would happen. And you are obviously aware of this since you considered those repercussions when making the decision. So please apologize for the mischaracterization and close to slander of that statement.
Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission.
There has been that argument. As Boost's mission is impacted by the people that volunteer considerable resources to make it survive. Until now the argument has fallen to not move to cmake. Please search the archives for such evidence.
The steering committee was created to protect the mission of Boost.
Hopefully you realize that the manner in which the SC operates is hurting the mission of Boost. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Le 19.07.17 à 14:27, Rene Rivera via Boost a écrit :
I hate getting into these kinds of arguments.. But this email is a bit too far for me to not respond.
On Wed, Jul 19, 2017 at 6:05 AM, David Sankel via Boost < boost@lists.boost.org> wrote:
Boost needs a steering committee to break stalemates and that is why it was created and exists today.
There was no stalemate. Almost every time cmake has been brought up there's been a discussion as to the merits of the build system and the impact on switching. Until now the SC never got involved.
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
No. There where never any threats. Only statements of what would happen. And you are obviously aware of this since you considered those repercussions when making the decision. So please apologize for the mischaracterization and close to slander of that statement.
Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission.
There has been that argument. As Boost's mission is impacted by the people that volunteer considerable resources to make it survive. Until now the argument has fallen to not move to cmake. Please search the archives for such evidence.
@Rene: I am fully backing you on this, Rene. My understanding of the cmake topic so far can be summarized like this: 1. Someone says: "cmake is cool, let's move to cmake! (smiley smiley)" 2. "ok, what do we need?" 3. "we need those features: [very ... very long list]" 4. "ok, who is doing what?" 5. Someone says: "I can pick the first two of that list" ... optionally later says, "we do not need the other features". 6. (some random time oblivion) 7. (void or close to it) 8. go back to 1. And I started subscribing to the list only in 2014. So now that there is an official statement from the Steering Committee, that is not only on which folder should receive the CMakeLists.txt, I am really wondering who will do what, and I am eager to see the final code. The cmake track has been enabled, now we need doers. Raffi PS: Of course, this post does not help anything, but I do not want Boost to be in the same spirit as GoT.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Raffi Enficiaud via Boost Sent: 19 July 2017 14:15 To: boost@lists.boost.org Cc: Raffi Enficiaud Subject: Re: [boost] CMake Announcement from Boost Steering Committee
Le 19.07.17 à 14:27, Rene Rivera via Boost a écrit :
I hate getting into these kinds of arguments.. But this email is a bit too far for me to not respond.
On Wed, Jul 19, 2017 at 6:05 AM, David Sankel via Boost < boost@lists.boost.org> wrote:
Boost needs a steering committee to break stalemates and that is why it was created and exists today.
There was no stalemate. Almost every time cmake has been brought up there's been a discussion as to the merits of the build system and the impact on switching. Until now the SC never got involved.
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
No. There where never any threats. Only statements of what would happen. And you are obviously aware of this since you considered those repercussions when making the decision. So please apologize for the mischaracterization and close to slander of that statement.
Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission.
There has been that argument. As Boost's mission is impacted by the people that volunteer considerable resources to make it survive. Until now the argument has fallen to not move to cmake. Please search the archives for such evidence.
@Rene: I am fully backing you on this, Rene.
My understanding of the cmake topic so far can be summarized like this: 1. Someone says: "cmake is cool, let's move to cmake! (smiley smiley)" 2. "ok, what do we need?" 3. "we need those features: [very ... very long list]" 4. "ok, who is doing what?" 5. Someone says: "I can pick the first two of that list" ... optionally later says, "we do not need the other features". 6. (some random time oblivion) 7. (void or close to it) 8. go back to 1.
And I started subscribing to the list only in 2014. So now that there is an official statement from the Steering Committee, that is not only on which folder should receive the CMakeLists.txt, I am really wondering who will do what, and I am eager to see the final code.
The cmake track has been enabled, now we need doers.
+1 - CMake is voodoo to me ;-) And, like Homer, my brain is full - of bjam/b2. One or two CMake knowledgeable people have poked their heads above the parapet but so far we only have a good proof-of-concept example by Peter Dimov - but one trivially simple by comparison with many libraries. So we are going to need people who have skills in both bjam *and* CMake in order to make the transition. (So PLEASE don't take your bat home Rene - we need you more than ever! Keep up the sterling service.) To progress beyond statements of desire and intent, we need to have quite a lot of doers to convert some existing libraries to build using CMake. The subset including at least system, chrono and Boost.Test (used by nearly all libraries) for starters, and then at least a couple of BIG libraries. Only once we get to that point can we be serious about making a change, whatever the Boost Steering Committee may say now. Doers? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 7/19/17 7:47 AM, Paul A. Bristow via Boost wrote:
To progress beyond statements of desire and intent, we need to have quite a lot of doers to convert some existing libraries to build using CMake. The subset including at least system, chrono and Boost.Test (used by nearly all libraries) for starters, and then at least a couple of BIG libraries.
FWIW - I've included CMakeLists.txt file in the serialization library for some years. I use it to build and test the serialization library. Actually I used it to build the IDE project which I can then use to build and test the serialization library. Which I believe qualifies as a BIG library. The reason I made this effort was that I like and depend upon the IDE for editing, testing, and working with integrated GIT functionality (I'm currently using Xcode). Before making the CMake files I had to maintain the IDE project by hand - not really a practical task. It was easier to figure out CMake - not a trivial task - than to figure out the xcode ide configuration. Here are some interesting points. a) It only builds and tests the serialization library. It doesn't provide the Find... functionality for users. As as library developer I don't really care about users (for all you sad humorless readers - that is a joke. It's depressing that I have to include this disclaimer.) But it's been there for years and no one has ever asked for this functionality. b) As far as I know, I'm the only person on the planet who has ever used this facility - even though it is plain to see for anyone interested. c) It wasn't that hard to setup and maintain - once you spend a non trivial amount of time learning to really understand CMake. Reading the comments on this lists make me think that many commentators have only a cursory knowledge of CMake. Like other build tools, it looks easy when you make a simple toy project - then you need something trivial that doesn't come out of the box (e.g. test compilation failure) you find that it's incredibly difficult and time consuming to add and the result is hacky and fragile and not really understandable. d) It does produce an acceptable project for my IDE. Anyone who is actually interested can use their copy of CMake to test this out by creating IDE project files for their own environment. Again, as far as I know I'm the only person (safe one other) who has ever done this. e) It depends on the rest of boost having been compiled to produce librarie which are consumable. These are built with the normal b2 system. Conclusion: This process doesn't have to be as traumatic as it's been made out to be. If promoters of CMake want to invest actual effort, they might provide tools/templates for doing this and let people start using them. If there is a need to force them, you've probably not got it right yet.
Doers? LOL - don't hold your breath
Paul
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
Really. Just as my blood pressure was considering the option of going back to normal. Suppose for the sake of argument that we all agree that we want Boost to move to CMake. We're here - Boost works, but is Boost.Build-based - and we want to move there - Boost works and is CMake-based. There are two ways to do it. The first one is a gradual transition. We currently have two pieces of critical infrastructure reliant on Boost.Build - the test system and the build/install procedure. (Three actually if we include the doc build.) How would a gradual transition work? For the testing part, obviously, we keep the Boost.Build testing operational and start building a parallel test infrastructure based on CMake/CTest. Libraries that want to be tested via b2 supply test/Jamfile, libraries that want to be tested via CTest supply... test/CMakeLists.txt, for instance. Libraries that supply neither aren't tested by either. For the building part, we start supplying a secondary way to build and install Boost, alongside the existing one. The second possibility is a sudden jump. We move, for both testing and building, to CMake at once. How would this be best handled? By building the CMake infrastructure on a branch until it's ready for the switch. Organizationally speaking, what needed to be done? First, we choose which scenario we prefer. Second, the SC appoints a person in charge of realizing the plan. If gradual, he sets off to work with the results immediately appearing in Boost as libraries are picked up by the CMake test/build infrastructure one by one. If sudden, he sets off to work on his branch. When ready, the SC votes on the switch. So far I have left unspoken something that everyone should have picked up - the role of Rene in all this. It's patently obvious that a gradual transition would be much (much!) harder without him around, so we've pretty much ruled that possibility out now. This was, in my opinion, completely unnecessary. Or was it?
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
To put it bluntly, did the glorious CMake transition HAVE to start with killing the workhorse and driving away the rider who got us where we are? And even if some of you believe that the answer to this question is "yes, it did have", can you not at least bring yourselves to not state that openly? Boost.Build and Rene have done a lot for the C++ community. Unless and until you can match this track record...
On 19/07/2017 16:33, Peter Dimov via Boost wrote:
Organizationally speaking, what needed to be done? First, we choose which scenario we prefer. Second, the SC appoints a person in charge of realizing the plan. If gradual, he sets off to work with the results immediately appearing in Boost as libraries are picked up by the CMake test/build infrastructure one by one. If sudden, he sets off to work on his branch. When ready, the SC votes on the switch.
So far I have left unspoken something that everyone should have picked up - the role of Rene in all this. It's patently obvious that a gradual transition would be much (much!) harder without him around, so we've pretty much ruled that possibility out now. This was, in my opinion, completely unnecessary.
Or was it?
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
To put it bluntly, did the glorious CMake transition HAVE to start with killing the workhorse and driving away the rider who got us where we are?
Thanks Peter. I think you've expressed very precisely what I (and maybe others) think. We want both Rene and Jon in Boost. Ion
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Ion Gaztañaga via Boost Sent: 19 July 2017 16:21 To: boost@lists.boost.org Cc: Ion Gaztañaga Subject: Re: [boost] CMake Announcement from Boost Steering Committee
On 19/07/2017 16:33, Peter Dimov via Boost wrote:
Organizationally speaking, what needed to be done? First, we choose which scenario we prefer. Second, the SC appoints a person in charge of realizing the plan. If gradual, he sets off to work with the results immediately appearing in Boost as libraries are picked up by the CMake test/build infrastructure one by one. If sudden, he sets off to work on his branch. When ready, the SC votes on the switch.
So far I have left unspoken something that everyone should have picked up - the role of Rene in all this. It's patently obvious that a gradual transition would be much (much!) harder without him around, so we've pretty much ruled that possibility out now. This was, in my opinion, completely unnecessary.
Or was it?
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
To put it bluntly, did the glorious CMake transition HAVE to start with killing the workhorse and driving away the rider who got us where we are?
Thanks Peter. I think you've expressed very precisely what I (and maybe others) think.
We want both Rene and Jon in Boost.
+1 And we need lots of new blood capable of implementing Boost using CMake with lots of time and energy, enthusiasm and stamina. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
There are two ways to do it. The first one is a gradual transition. We currently have two pieces of critical infrastructure reliant on Boost.Build - the test system and the build/install procedure. (Three actually if we include the doc build.)
How would a gradual transition work? For the testing part, obviously, we keep the Boost.Build testing operational and start building a parallel test infrastructure based on CMake/CTest. Libraries that want to be tested via b2 supply test/Jamfile, libraries that want to be tested via CTest supply... test/CMakeLists.txt, for instance. Libraries that supply neither aren't tested by either.
For the building part, we start supplying a secondary way to build and install Boost, alongside the existing one.
The second possibility is a sudden jump. We move, for both testing and building, to CMake at once.
I don't believe that can work: the CMake branch would never keep up with a constantly changing/evolving develop. Frankly unless there are a huge amount of resources (probably at least one full time developer keeping the CMake branch on track with develop), I see this as a non-starter. Remember this was in effect tried before, as I recall it failed because it just couldn't keep up despite Boost.Consulting's resources behind it. What might work, is a "lot of little bangs", moving one whole library at a time to CMake. My concern is that folks leave the difficult stuff to last, get bored, move on, and we're left stuck with a semi-working mess. Frankly, I simply do not know enough about CMake to know if this move is a good thing thing or not, but I am completely certain that there are a lot of folks greatly under-estimating the amount of work involved here. And now I'll go back to lurking again... John.
How would this be best handled? By building the CMake infrastructure on a branch until it's ready for the switch.
Organizationally speaking, what needed to be done? First, we choose which scenario we prefer. Second, the SC appoints a person in charge of realizing the plan. If gradual, he sets off to work with the results immediately appearing in Boost as libraries are picked up by the CMake test/build infrastructure one by one. If sudden, he sets off to work on his branch. When ready, the SC votes on the switch.
So far I have left unspoken something that everyone should have picked up - the role of Rene in all this. It's patently obvious that a gradual transition would be much (much!) harder without him around, so we've pretty much ruled that possibility out now. This was, in my opinion, completely unnecessary.
Or was it?
The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.
To put it bluntly, did the glorious CMake transition HAVE to start with killing the workhorse and driving away the rider who got us where we are?
And even if some of you believe that the answer to this question is "yes, it did have", can you not at least bring yourselves to not state that openly?
Boost.Build and Rene have done a lot for the C++ community. Unless and until you can match this track record...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- This email has been checked for viruses by AVG. http://www.avg.com
Den 19-07-2017 kl. 14:05 skrev David Sankel via Boost:
On Tue, Jul 18, 2017 at 5:00 PM, Vladimir Prus via Boost < boost@lists.boost.org> wrote:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our
desire and intent to move Boost’s build system to CMake for users and developers alike.
Since its founding, Boost was run by open discussions on a mailing list.
Boost needs a steering committee to break stalemates and that is why it was created and exists today. The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats. Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission. Enough is enough. "Finally" is the word I keep seeing over and over on the reddit discussion.
Well, there are consumers and developers. I don't doubt that many consumers would appreciate support for CMake. But that should rule out the possibility that boost internally just uses something else, should it?
The steering committee was created to protect the mission of Boost. It is comprised of Boost developers, users, and leaders in the C++ community. Everyone on that committee is looking out for the best interests of Boost and is well qualified to do so. The decision to move to CMake was made unanimously.
[snip]
The steering committee is set up like many others in the Open Source world. People are chosen for various reasons but primary among them is their commitment to Boost's mission and doing what is right for Boost. This is how the founders set it up and how Boost ever switched to git.
[snip]
I'm sorry you and a couple others aren't happy with the decision made, but any decision in a deadlock situation is bound to disappoint someone.
“I trust that every animal here appreciates the sacrifice that Comrade Napoleon has made in taking this extra labour upon himself. Do not imagine, comrades, that leadership is a pleasure! On the contrary, it is a deep and heavy responsibility. No one believes more firmly than Comrade Napoleon that all animals are equal. He would be only too happy to let you make your decisions for yourselves. But sometimes you might make the wrong decisions, comrades, and then where should we be?” kind regards Thorsten
Den 18-07-2017 kl. 23:00 skrev Vladimir Prus via Boost:
On 18/07/2017 16:12, Jon Kalb via Boost wrote:
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.
[snip]
However, I can't call this decision process anything but broken. Since its founding, Boost was run by open discussions on a mailing list.
Very broken if this is the way the SC is going to announce things. [snip]
There is no doubt that all SC members mean only good for Boost and C++ community,
I think they mean well, but one man's definition of "good" may not equal another man's. However, the lack of SC people actually participating in this thread is not a good sign. [snip]
I think that for future of Boost, it would be better if the Steering Committee immediately resign, and have an open election process for its replacement. Personally, I'll be happy to vote for many current members, but I feel that a governance based on open process will be better in the long run.
I don't know about that. The rules say: "[...] It is not the role of the Steering Committee to inhibit this kind of spontaneous leadership and action, which has served Boost and the wider C++ community so well. On the contrary, it is the role of the Steering Committee to facilitate community-based leadership and decision making. The role of the Committee is to be able to commit the organization to specific action either where funds are required or where consensus cannot be reached, but a decision must be made." Did we see any community-based leadership and decision making? How do one know/decide that a decision /must/ be made? kind regards Thorsten
Thanks for announcing this, Jon, and thanks to the Steering Committee for making a decision.
From where I am sitting, CMake is the clear winner of the "build system war". Regardless of how you personally feel about the technical merits, it is hard to argue that Boost as a project and a community is not better off due to this change.
To some people, this seems out of the blue. To me, this seems inevitable. There have been many discussions on the Boost mailing list over the past months (years, even) about having CMake be a requirement for new libraries and using it as the default build system. We, as a community, pride ourselves on keeping up with modern software development practices. In C++, that increasingly means using CMake. We should not be concerned that we will be unable to make the change -- projects far larger and more complicated than ours build on CMake already. That's one of the advantages of making use of tools that have broad support: most of the work is already done. If you imagine two possible futures: one in which Boost uses CMake as the build system and one in which it uses b2, which future do you imagine is better for Boost in the coming years?
+1000. I think you summed up my feelings as well. Having the SC step in now was a good move. At some point, arguments like "tabs vs spaces" stop going anywhere because people dig in (often for good reasons, on both sides), and it's easy to stalemate -- although I think the community was moving towards cmake consensus naturally, based on the recent discussions. This decision lets us get past the distraction of arguing what's best and move on to what really matters: How to get there. Jared
El jul. 18, 2017, a las 17:22, David Stone via Boost <boost@lists.boost.org> escribió:
Thanks for announcing this, Jon, and thanks to the Steering Committee for making a decision.
From where I am sitting, CMake is the clear winner of the "build system war". Regardless of how you personally feel about the technical merits, it is hard to argue that Boost as a project and a community is not better off due to this change.
To some people, this seems out of the blue. To me, this seems inevitable. There have been many discussions on the Boost mailing list over the past months (years, even) about having CMake be a requirement for new libraries and using it as the default build system. We, as a community, pride ourselves on keeping up with modern software development practices. In C++, that increasingly means using CMake.
We should not be concerned that we will be unable to make the change -- projects far larger and more complicated than ours build on CMake already. That's one of the advantages of making use of tools that have broad support: most of the work is already done.
If you imagine two possible futures: one in which Boost uses CMake as the build system and one in which it uses b2, which future do you imagine is better for Boost in the coming years?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/20/2017 2:35 PM, Jared Grubb via Boost wrote: 2c:
Having the SC step in now was a good move. At some point, arguments like "tabs vs spaces" stop going anywhere because people dig in (often for good reasons, on both sides), and it's easy to stalemate -- although I think the community was moving towards cmake consensus naturally, based on the recent discussions.
Only a small part of the community engaged in that discussion. Some of us didn't bother to engage because our opinion was already being voiced by others. There was no vote across the developers or even the mailing list as a whole. There was just (yet another) random argument on the mailing list that carries no usable statistical information at all.
El jul. 18, 2017, a las 17:22, David Stone via Boost <boost@lists.boost.org> escribió:
From where I am sitting, CMake is the clear winner of the "build system war". Regardless of how you personally feel about the technical merits, it is hard to argue that Boost as a project and a community is not better off due to this change.
To some people, this seems out of the blue. To me, this seems inevitable. There have been many discussions on the Boost mailing list over the past months (years, even) about having CMake be a requirement for new libraries and using it as the default build system. We, as a community, pride ourselves on keeping up with modern software development practices. In C++, that increasingly means using CMake.
Technical merit is all that matters. We shouldn't be following the popular vote of the unwashed masses. Boost should be leading--which is really what Boost was about--not "reaching the most people."
If you imagine two possible futures: one in which Boost uses CMake as the build system and one in which it uses b2, which future do you imagine is better for Boost in the coming years?
What is better is for Boost to return to what it once was--a bastion of pioneering innovation that pushed the state of the art. That implies that "doing things the way everybody else does just because" is not an argument. Sadly, Boost appears to me to have progressively degenerated and is rapidly approaching mediocrity. CMake is just one more step in that direction. The SC can go ahead and implement everything themselves while all the people that did all the real work leave. What a colossal example of arrogance and overstepping. I agree with Vladimir Prus except that I wouldn't vote to reelect any of them--including those that have contributed to Boost. And, no, Niall, having done some good does not make someone above reproach. Regards, Paul Mensonides
On 21/07/2017 02:26, Paul Mensonides via Boost wrote:
On 7/20/2017 2:35 PM, Jared Grubb via Boost wrote:
From where I am sitting, CMake is the clear winner of the "build system war". Regardless of how you personally feel about the technical merits, it is hard to argue that Boost as a project and a community is not better off due to this change.
To some people, this seems out of the blue. To me, this seems inevitable. There have been many discussions on the Boost mailing list over the past months (years, even) about having CMake be a requirement for new libraries and using it as the default build system. We, as a community, pride ourselves on keeping up with modern software development practices. In C++, that increasingly means using CMake.
Technical merit is all that matters. We shouldn't be following the popular vote of the unwashed masses. Boost should be leading--which is really what Boost was about--not "reaching the most people." Great, we can drop support for all those platforms and compilers people should not be using anymore. And C++11 was so 200X anyway. Actually, why stick to C++ ? D is the future!
If you imagine two possible futures: one in which Boost uses CMake as the build system and one in which it uses b2, which future do you imagine is better for Boost in the coming years?
What is better is for Boost to return to what it once was--a bastion of pioneering innovation that pushed the state of the art. A pioneer is someone who's comes first and then is followed by the masses. As far as bjam is concerned, it seems it's been stuck in phase 1 for quite a few years now. Boost is a collection C++ libraries, maybe innovation should focus on that.
Alain
That implies that "doing things the way everybody else does just because" is not an argument.
Sadly, Boost appears to me to have progressively degenerated and is rapidly approaching mediocrity. CMake is just one more step in that direction.
The SC can go ahead and implement everything themselves while all the people that did all the real work leave. What a colossal example of arrogance and overstepping. I agree with Vladimir Prus except that I wouldn't vote to reelect any of them--including those that have contributed to Boost. And, no, Niall, having done some good does not make someone above reproach.
Regards, Paul Mensonides
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The SC can go ahead and implement everything themselves while all the people that did all the real work leave. What a colossal example of arrogance and overstepping. I agree with Vladimir Prus except that I wouldn't vote to reelect any of them--including those that have contributed to Boost. And, no, Niall, having done some good does not make someone above reproach.
I have seen some enormously ignorant, petty and sanctimonious guff spoken here during this thread, sufficiently so that it makes Reddit look a positive bastion of enlightenment and positivity. It paints the Boost developer community in a sorry light, very sad. But I felt it was important for the SC to handle its own PR, so I have said nothing and will continue to do so. But as someone who has in the past strongly and repeatedly criticised the steering committee for doing no steering and being generally unfit for purpose, I now find myself morally obliged to defend it for doing some steering finally, especially as by making decisions which are actually controversial it is finally fit for purpose and demonstrates the long absent vigour finally returning to this community after nearly a decade of moribund, directionless stagnation. There are lots of good reasons why library developers should not be a majority on the steering committee, and hence are not: 1. Library developers see the world as a top 1% experienced elite C++ developer. They frequently, if not usually, fail to see that same world from the perspective of the 99% of everybody else, and often are *incapable* of seeing that same world from the perspective of the majority. Bjarne has often said publicly that Boost's biggest design flaw is how hard it is to get up and running with it quickly: - Why are top layer APIs riddled with templates instead of being hidden behind simplified convenience typedefs and non-template conventional OO class designs instead? - Why if most of the library is header only capable can't you just drop in a single header file and get to work? - Why is it acceptable for compile times to be so severely affected for end users? ... and the list goes on (more at http://www.stroustrup.com/bs_faq.html#boost). And how many times have I and other end users said the same now? Yet some library developers don't care: they want their cathedral pure and beautiful. And damn the end users if they are too stupid or ignorant to appreciate that cathedral in its untainted majesty. Well, that's just ignorant and self serving elitism. We can do a lot better, be friendlier, more welcoming, more inclusive, make things easier rather than harder for everybody else in C++. After all C++ is fighting for its life against the upstart systems languages, we don't have the luxury to being mean to end users anymore. A steering committee of non-Boost-developers stands a far better chance of seeing the bigger, wider, long term sustainable picture than individual library developers unwilling to look outside their own library's limited silo, and their own limited and narrow self interests. 2. Library developers tend to love coding, else they wouldn't have invested the many years of unpaid effort to get a library into Boost. As a general rule, but not always, people who love coding don't much like doing non-technical admin. It can be the case that people who don't much like doing non-technical admin don't realise how hard it is to be even reasonably competent at it, they think it surely must be easy to shepherd cats because people who do it tend to currently be paid less and have currently lower social status than they have. What they forget however is that shepherding cats, especially when you can't bribe them to behave with regular payments of money better known as "a salary", is extremely hard. *Far* harder than getting a library into Boost. And to be even remotely competent at it when you can't bribe people with "salary" is rare. Now Boost has been enormously fortunate to have the treasure which is Jon Kalb and the ecosystem of people around him which makes so much of Boost and C++ "just happen" without it being obviously made to happen. These people don't appear here, indeed most don't even subscribe to boost-dev because they are not library developers. But they are **just as important** to making Boost work and function as all the library developers and maintainers are. If they all quit, the website, mailing list, library releases, conferences, and **all your hard work on your library** stops happening. Moreover, **C++ itself** stops happening as a viable long term programming language. That means that the 10,000+ hours you've invested in your career and training becomes **worthless**. That eventually means dumping another 10,000+ hours into something else like Rust or Swift, but most of us aren't that young and free anymore. We're locked into C++. So stop dumping hate on the non-technical admin side of Boost and C++. If you have a problem with them, it's the same as library development: if you'd like the non-technical admin to be done differently, **volunteer** and join the small army who do the non-technical admin. Otherwise stop whining when they take decisions that you don't like. If you had taken any time to be familiar with what is discussed in the non-technical admin community, then this decision about cmake above was obviously coming over this past year. I was part of multiple off list discussions, and that was a small subset of the total ongoing. Indeed, it's why I've been so sweetness and nice here on boost-dev in the past year, I was finally seeing some movement on choosing a direction for Boost after many years of trying to no avail. So no longer any need to be nasty here anymore. And for the record, more controversial breaking change is coming. So don't be surprised when it lands. 3. Boost is very fortunate and unusual amongst open source projects to be very wealthy. They have more than enough money to employ contractors at US market day rates to implement a complete cmake transition in weeks if they so chose. However they do not wish to do that if it can at all be avoided. It is felt that a spontaneously designed and implemented cmake solution by the community for the community would be much better in terms of coming up with the right design, and generating buy in amongst a critical mass. Now I'll freely admit as a veteran contributor to the Boost git migration that I find that unrealistically naive. I think it can only work if you drop half the Boost libraries with more complex build needs from the distro, and as much as dropping half the libraries is something I personally want too, the problem is that those halves are not the same halves. I want the undermaintained half of libraries dropped, not the well maintained libraries with complex build needs. Anyway, I'm not on the SC, so I can't say what discussions have been happening off list about that. But I can say that there have been discussions, I have occasionally been looped in off list on specific points only. If the SC were all library developers, I think there would be a temptation to spend some of that cash pile on library development - I certainly would, but then I'm a library developer. I may not personally agree with the rationale to never spend money on development as has historically been held by the SC, but I do understand its logic: the money is there to lubricate and facilitate, not to drive development or admin itself. The current rough balance of half non-technical admin and half library developers on the Boost SC is probably therefore ideal, despite that from boost-dev's perspective the non-technical admin obviously contribute nothing useful. There will no doubt be lots of angry responses to this. And I apologise in advance to those on the SC that I promised I would not participate in this thread. But hey, you guys been taking a beating both here and on Reddit, and I know from off list discussions that it's gotten some of you very down. I want you to know that despite our past differences, I have your back. Breaking change is always unpopular, that's why it's so vital to do it regularly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Fri, Jul 21, 2017 at 4:41 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
- Why are top layer APIs riddled with templates instead of being hidden behind simplified convenience typedefs and non-template conventional OO class designs instead?
I, for one, am grateful that `boost::shared_ptr` is declared as a class template rather than a class. Thanks
On 07/21/2017 01:41 PM, Niall Douglas via Boost wrote: <snip>
Bjarne has often said publicly that Boost's biggest design flaw is how hard it is to get up and running with it quickly:
- Why are top layer APIs riddled with templates instead of being hidden behind simplified convenience typedefs and non-template conventional OO class designs instead? - Why if most of the library is header only capable can't you just drop in a single header file and get to work? - Why is it acceptable for compile times to be so severely affected for end users?
... and the list goes on (more at http://www.stroustrup.com/bs_faq.html#boost). And how many times have I and other end users said the same now? Yet some library developers don't care: they want their cathedral pure and beautiful. And damn the end users if they are too stupid or ignorant to appreciate that cathedral in its untainted majesty.
Actually, there are exactly two items in your source: "- It is too hard to download and use just one Boost library; the libraries seem overly coupled making it hard to pick and choose. - Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost." - Bjarne Stroustrup So much for that, if you cite someone, you should at least do it properly.
Actually, there are exactly two items in your source: "- It is too hard to download and use just one Boost library; the libraries seem overly coupled making it hard to pick and choose. - Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost." - Bjarne Stroustrup
So much for that, if you cite someone, you should at least do it properly.
It wasn't a cited source, it was a link to more detail. I was citing Bjarne's public comments on Boost in interviews, in his conference talks as well as his website. His opinion regarding Boost is very well known. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/21/2017 02:12 PM, Niall Douglas via Boost wrote:
Actually, there are exactly two items in your source: "- It is too hard to download and use just one Boost library; the libraries seem overly coupled making it hard to pick and choose. - Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost." - Bjarne Stroustrup
So much for that, if you cite someone, you should at least do it properly.
It wasn't a cited source, it was a link to more detail. I was citing Bjarne's public comments on Boost in interviews, in his conference talks as well as his website. His opinion regarding Boost is very well known.
Obviously you know more than I do. Do you mind sharing those interviews/comments and/or recorded talk?
Niall
Den 21-07-2017 kl. 13:41 skrev Niall Douglas via Boost:
The SC can go ahead and implement everything themselves while all the people that did all the real work leave. What a colossal example of arrogance and overstepping. I agree with Vladimir Prus except that I wouldn't vote to reelect any of them--including those that have contributed to Boost. And, no, Niall, having done some good does not make someone above reproach.
I have seen some enormously ignorant, petty and sanctimonious guff spoken here during this thread, sufficiently so that it makes Reddit look a positive bastion of enlightenment and positivity. It paints the Boost developer community in a sorry light, very sad. But I felt it was important for the SC to handle its own PR, so I have said nothing and will continue to do so.
Right. Where is the SC?
So stop dumping hate on the non-technical admin side of Boost and C++. If you have a problem with them, it's the same as library development: if you'd like the non-technical admin to be done differently, **volunteer** and join the small army who do the non-technical admin. Otherwise stop whining when they take decisions that you don't like.
The problem might be that if you don't involve the developers, they get very offended, and for good reasons.
If you had taken any time to be familiar with what is discussed in the non-technical admin community, then this decision about cmake above was obviously coming over this past year. I was part of multiple off list discussions, and that was a small subset of the total ongoing. Indeed, it's why I've been so sweetness and nice here on boost-dev in the past year, I was finally seeing some movement on choosing a direction for Boost after many years of trying to no avail. So no longer any need to be nasty here anymore. And for the record, more controversial breaking change is coming. So don't be surprised when it lands.
Huh? More announcements of decisions behind closed doors without list discussions? Look, everybody here would like Boost to be easier to consume for end users. But that's a goal that needs a plan and means and feasibility studies. Secondary, should we abandon boost.build internally? That's a different thing entirely. I hope the SC realize how damaging their actions are. -Thorsten
The problem might be that if you don't involve the developers, they get very offended, and for good reasons.
As no less than two members of the SC have already said here in this thread, boost-dev was consulted and in depth, with at least three boost-dev members proposing technical cmake solution prototypes for the SC to consider. The same old arguments were made, nothing new over previous discussions of the merits or non-merits of cmake vs boost.build were advanced. The SC therefore decided that this decision was making no progress due to stalemate, and enforced a decision. You probably wanted some big banner in the Subject line like "IF YOU DON'T SPEAK NOW THEN CMAKE IS HAPPENING". But the way that the SC was originally set up doesn't allow that to happen. Nobody from the SC can claim that the SC will take some action until they *have* taken some action, and they can't take an action until a *formal* written proposal has been laid before them to vote upon. Formal written proposals land before the SC to vote on all the time. Some are rejected, some approved. I've written a few myself, but not recently as I am winding down my involvement with Boost.
If you had taken any time to be familiar with what is discussed in the non-technical admin community, then this decision about cmake above was obviously coming over this past year. I was part of multiple off list discussions, and that was a small subset of the total ongoing. Indeed, it's why I've been so sweetness and nice here on boost-dev in the past year, I was finally seeing some movement on choosing a direction for Boost after many years of trying to no avail. So no longer any need to be nasty here anymore. And for the record, more controversial breaking change is coming. So don't be surprised when it lands.
Huh? More announcements of decisions behind closed doors without list discussions?
All stakeholders involved in the cmake decision were consulted in depth and many weeks in advance. There was nothing closed door about it. Search the boost-dev archives, it's there.
Look, everybody here would like Boost to be easier to consume for end users. But that's a goal that needs a plan and means and feasibility studies. Secondary, should we abandon boost.build internally? That's a different thing entirely.
I hope the SC realize how damaging their actions are.
You all should read the announcement again. The only decision enforced was that cmake is going to happen. Nothing was said about form, design, process, timetable, or anything else. Nothing was said about removing Boost.Build either. Quite frankly the reaction here was way overblown to what had happened. But then if you don't maintain a steady beat of breaking change, people way overreact when it comes. And we haven't had a breaking change here since the git migration five years ago. And that was *awful*. So far, this is going better. Long may it continue. Nothing in any of this reply has not already been previously said on this thread by SC members. I am, quite literally, repeating what they already have said here, despite that I am not a member of the SC. I just pay attention to what people write on boost-dev. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Fri, Jul 21, 2017 at 10:30 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
Formal written proposals land before the SC to vote on all the time. Some are rejected, some approved. I've written a few myself, but not recently as I am winding down my involvement with Boost.
Where do we find the archive of all those proposals, along with outcomes of the voting? -- Olaf
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 21 July 2017 12:41 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] CMake Announcement from Boost Steering Committee
<snip>
3. Boost is very fortunate and unusual amongst open source projects to be very wealthy. They have more than enough money to employ contractors at US market day rates to implement a complete cmake transition in weeks if they so chose.
However they do not wish to do that if it can at all be avoided. It is felt that a spontaneously designed and implemented cmake solution by the community for the community would be much better in terms of coming up with the right design, and generating buy in amongst a critical mass.
Nobody has yet stepped up to do this :-( So are the Steering Committee now going to put money into actually implementing Boost/CMake? (And I trust that means converting the working bjam/b2 jamfiles fully for all libraries, not just the simple ones. I'd strongly opposed to ditching libraries just because their build is troublesome for CMake). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Niall Douglas wrote:
Well, that's just ignorant and self serving elitism.
Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake.
A steering committee of non-Boost-developers stands a far better chance of...
... changing Boost into non-Boost, because everyone feels the need to remake things that are alien to him in his own image. Boost has been created and has been maintained (not just in a technical sense) by developers, and what it is today reflects it. A steering committee of non-Boost-developers is capable of producing something good, but this good thing will no longer be Boost, except by name.
On 18 July 2017 at 16:59, Rene Rivera via Boost <boost@lists.boost.org> wrote:
On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
As a consequence.. I herby resign from all my duties in the Boost community effectively immediately. This means that I will no longer be in the Release Team.
Since none of the current Boost Steering Committee members are owners in the Github Boost.ORG organization.. Could one of the github owners please change my role from "owner" to "member"? (github doesn't allow you to do that to yourself).
Done. I'm very sorry that to see you resign, especially under these circumstances. Thanks for all you've contributed over the years.
Den 21-07-2017 kl. 18:23 skrev Daniel James via Boost:
On 18 July 2017 at 16:59, Rene Rivera via Boost <boost@lists.boost.org> wrote:
On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
As a consequence.. I herby resign from all my duties in the Boost
[snip]
Done. I'm very sorry that to see you resign, especially under these circumstances. Thanks for all you've contributed over the years.
Hear hear. kind regards Thorsten
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen via Boost Sent: 24 July 2017 10:14 To: boost@lists.boost.org Cc: Thorsten Ottosen Subject: Re: [boost] CMake Announcement from Boost Steering Committee
Den 21-07-2017 kl. 18:23 skrev Daniel James via Boost:
On 18 July 2017 at 16:59, Rene Rivera via Boost <boost@lists.boost.org> wrote:
On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
As a consequence.. I herby resign from all my duties in the Boost
[snip]
Done. I'm very sorry that to see you resign, especially under these circumstances. Thanks for all you've contributed over the years.
+1 Your abrupt departure is quite understandable (and most regrettable). To me, the trigger for it was most tactless. Moving to CMake will be much harder without your help, even if given reluctantly. Very, very many thanks for all your hard and invaluable work over so many years. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 21/07/2017 16:55, Peter Dimov via Boost wrote:
Niall Douglas wrote:
Well, that's just ignorant and self serving elitism.
Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake.
Some would say that what has been achieved so far is a pale shadow of what would have been achieved without the self-serving elitism. If you look at the bits of Boost which got into the C++ standard, they are very obviously the simple bits. There's a lesson in that.
A steering committee of non-Boost-developers stands a far better chance of...
... changing Boost into non-Boost, because everyone feels the need to remake things that are alien to him in his own image.
Boost has been created and has been maintained (not just in a technical sense) by developers, and what it is today reflects it. A steering committee of non-Boost-developers is capable of producing something good, but this good thing will no longer be Boost, except by name.
No, Boost has been created and has been maintained and funded by its three main stakeholders, only one of which is Boost library developers. Boost library developers are a quarter to a third of that stakeholdership - important, sure, but not a majority like they think they are. A big stakeholder is the user base, most of whom are thrilled with this decision, mostly by its symbolic significance rather than any love of cmake. The other big stakeholder is the C++ leadership and WG21, most of whom are also pleased with this decision as it suggests Boost may yet have some relevance as a standards incubator into the future. Now, none of the above will be popular things to say on boost-dev, there is a widespread belief here that Boost can't exist without the library developers and that's all that matters. But equally, Boost can't exist without the C++ ecosystem either, nor can it exist without the people who behind the scenes make the mailing list, website, servers and financial accounts all work. And call me old fashioned, but Boost can't exist without users using it either. Anyone can build a marvelous cathedral. But what's the point if nobody ever marvels at it because nobody ever uses it? I really think that top quality libraries can never be truly top quality unless there is a significant, large, enthusiastic user base for them who finds them amazing. Bigger the better. You need to *know* your cathedral is marvelous through userbase, not just believe it personally. I *definitely* don't think libraries should be standardised without that for sure, and remember Boost was originally set up as an incubator for libraries to be standardised. The end users are in my belief the most important and biggest stakeholder of all. We need to do a lot better by them than we have. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
Well, that's just ignorant and self serving elitism.
Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake.
Some would say that what has been achieved so far is a pale shadow of what would have been achieved without the self-serving elitism.
Indeed they would. And the best thing about saying it is that it's unfalsifiable. If only Boost were what you think it should have been, it would have been at least 118% more successful. Hypotheticals aside, here in the real world we only have actual observable results on which to base our conclusions.
Am 21.07.2017 um 22:50 schrieb Niall Douglas via Boost:
On 21/07/2017 16:55, Peter Dimov via Boost wrote:
Niall Douglas wrote:
Well, that's just ignorant and self serving elitism. Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake. Some would say that what has been achieved so far is a pale shadow of what would have been achieved without the self-serving elitism. If you look at the bits of Boost which got into the C++ standard, they are very obviously the simple bits. There's a lesson in that. Let's see:
Without templates - boost.system_error - boost.error_code - boost.thread - boost.filesystem With type erasure: - boost.any - boost.function With templates: - boost.SmartPtr - boost.variant - boost.optional - boost.bind - boost.tuple Template black magic: - boost.type_traits - boost.asio (probably as the networking TS) - boost.EnableIf May I ask what you based your statement on? Did you even look at the list or would actually checking facts be elitism?
A steering committee of non-Boost-developers stands a far better chance of... ... changing Boost into non-Boost, because everyone feels the need to remake things that are alien to him in his own image.
Boost has been created and has been maintained (not just in a technical sense) by developers, and what it is today reflects it. A steering committee of non-Boost-developers is capable of producing something good, but this good thing will no longer be Boost, except by name. No, Boost has been created and has been maintained and funded by its three main stakeholders, only one of which is Boost library developers. Boost library developers are a quarter to a third of that stakeholdership - important, sure, but not a majority like they think they are. A big stakeholder is the user base, most of whom are thrilled with this decision, mostly by its symbolic significance rather than any love of cmake. The other big stakeholder is the C++ leadership and WG21, most of whom are also pleased with this decision as it suggests Boost may yet have some relevance as a standards incubator into the future.
Now, none of the above will be popular things to say on boost-dev, there is a widespread belief here that Boost can't exist without the library developers and that's all that matters. But equally, Boost can't exist without the C++ ecosystem either, nor can it exist without the people who behind the scenes make the mailing list, website, servers and financial accounts all work.
And call me old fashioned, but Boost can't exist without users using it either. Anyone can build a marvelous cathedral. But what's the point if nobody ever marvels at it because nobody ever uses it? I really think that top quality libraries can never be truly top quality unless there is a significant, large, enthusiastic user base for them who finds them amazing. Bigger the better. You need to *know* your cathedral is marvelous through userbase, not just believe it personally. Have you considered that most boost developers are users themselves? Because it sounds like you think none of the developers understands users, which seems like ignorant and self serving elitism to me.
On 7/21/17 1:50 PM, Niall Douglas via Boost wrote:
On 21/07/2017 16:55, Peter Dimov via Boost wrote:
Niall Douglas wrote:
Well, that's just ignorant and self serving elitism.
Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake.
Some would say that what has been achieved so far is a pale shadow of what would have been achieved without the self-serving elitism. If you look at the bits of Boost which got into the C++ standard, they are very obviously the simple bits. There's a lesson in that.
A steering committee of non-Boost-developers stands a far better chance of...
... changing Boost into non-Boost, because everyone feels the need to remake things that are alien to him in his own image.
Boost has been created and has been maintained (not just in a technical sense) by developers, and what it is today reflects it. A steering committee of non-Boost-developers is capable of producing something good, but this good thing will no longer be Boost, except by name.
No, Boost has been created and has been maintained and funded by its three main stakeholders, only one of which is Boost library developers.
Right - but that stakeholder does 99% of the actual work.
Boost library developers are a quarter to a third of that stakeholdership
where does one get such numbers? We don't any statistics on library usage. This goes not only for boost but for libraries std, CGal, etc. Sure we might have downloads (even that is suspect), but I'd be wary of citing such numbers - much less drawing conclusions from them.
- important, sure, but not a majority like they think they are. A big stakeholder is the user base, most of whom are thrilled with this decision,
right - but they don't do any actual work.
mostly by its symbolic significance rather than any love of cmake. The other big stakeholder is the C++ leadership and WG21, most of whom are also pleased with this decision
LOL - I don't see how anyone can know that.
as it suggests Boost may yet have some relevance as a standards incubator into the future.
Now, none of the above will be popular things to say on boost-dev, there is a widespread belief here that Boost can't exist without the library developers
LOL that is true by definition
and that's all that matters. But equally, Boost can't exist without the C++ ecosystem either, nor can it exist without the people who behind the scenes make the mailing list, website, servers and financial accounts all work.
I don't think these players have a big stake in he build system.
And call me old fashioned, but Boost can't exist without users using it either.
Again trivially true.
Anyone can build a marvelous cathedral. But what's the point if nobody ever marvels at it because nobody ever uses it? I really think that top quality libraries can never be truly top quality unless there is a significant, large, enthusiastic user base for them who finds them amazing. Bigger the better. You need to *know* your cathedral is marvelous through userbase, not just believe it personally.
Right - and we have absolutly no numbers or data on library usage - boost or otherwise
I *definitely* don't think libraries should be standardised without that for sure, and remember Boost was originally set up as an incubator for libraries to be standardised. The end users are in my belief the most important and biggest stakeholder of all. We need to do a lot better by them than we have.
Hmmm - My sense is that we've been doing better than everyone else out there. But again, it's just my sense given the incorporation of so many boost libaries into the standard. I (and no one else) really knows about this. I'm guessing that one reason the discussion is so contentious is the actual lack of factual information involved in it. Robert Ramey
On 21 July 2017 at 21:50, Niall Douglas via Boost <boost@lists.boost.org> wrote:
Now, none of the above will be popular things to say on boost-dev, there is a widespread belief here that Boost can't exist without the library developers and that's all that matters. But equally, Boost can't exist without the C++ ecosystem either, nor can it exist without the people who behind the scenes make the mailing list, website, servers and financial accounts all work.
The website was implemented and set up by Rene, and the bulk of the maintenance is done by boost developers. The people behind the scenes that you're suddenly so concerned about, include boost developers. Your claim about a widespread belief is both not true and insulting.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Jared Grubb via Boost Sent: 20 July 2017 22:35 To: Boost Developers List Cc: Jared Grubb; Jon Kalb Subject: Re: [boost] CMake Announcement from Boost Steering Committee
+1000. I think you summed up my feelings as well.
Having the SC step in now was a good move. At some point, arguments like "tabs vs spaces" stop going anywhere because people dig in (often for good reasons, on both sides), and it's easy to stalemate -- although I think the community was moving towards cmake consensus naturally, based on the recent discussions.
Nobody has been maintaining that there are more potential users of Boost who wish to use CMake.
This decision lets us get past the distraction of arguing what's best and move on to what really matters: How to get there.
The mailing list has recently been focussing on just that - the *how*. The *how* is looking feasible, but the *who* remains entirely unclear. So the Steering isn't going to happen without an engine of some expert volunteers with enthusiasm and time. I ask again ... who? Paul PS Especially as our most valuable packhorse has bolted in fright ;-) --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 2017-07-21 09:30, Paul A. Bristow via Boost wrote:
The mailing list has recently been focussing on just that - the *how*.
The *how* is looking feasible, but the *who* remains entirely unclear.
So the Steering isn't going to happen without an engine of some expert volunteers with enthusiasm and time.
I ask again ... who?
If you would like volunteers to do this, can I sign up to assist? I've been keen on being able to build Boost with CMake for years, but didn't get involved due to not being a core Boost person, just an end user, and also because it looked like there were also a bunch of keen people already working on it. But if you want additional people on board, I'd be happy to contribute in whatever way I can. As a bit of background, I'm a C++ programmer using Boost daily, but I also maintain CMake support stuff for my day job, and occasionally this involves helping upstream projects with their build systems as well. For example, my latest CMake work was adding CMake support to the venerable Apache Xerces-C++ library, and I've previously contributed CMake support to libtiff, bzip2 and others. I'm also one of the people who maintains FindBoost.cmake in the upstream CMake git repository, as well as other CMake features. Also, to expand upon one of Niall Douglas' points in his earlier email, regarding library developers not having the same worldview as the rest. Could I point to this trac ticket: https://svn.boost.org/trac10/ticket/1094 (this is about pkg-config support for Boost). This is one of the key deficiencies in Boost, as a project, in being difficult to use by downstream consumers, but it's been largely ignored and treated as unimportant. Ask yourself this question: I need to use Boost library XX. What are the transitive dependencies I need to link against in order to successfully build my stuff with XX? You have to find out, then hard-code it. Example: filesystem headers use system headers, and I need to know to link against system *and* filesystem if I use filesystem. And if these dependencies change in a new Boost release, your build breaks. I was already having problems with this a decade back when I filed the ticket, and it's only gotten worse. The reason I'm bringing this up here is that this ticket never got resolved because it required some knowledge of Boost.Build to complete. I didn't have that expertise, and apparently no one else did either. Even after asking several times on IRC, the lists etc., no one ever offered to help with this, and so it got stalled. Having a custom and baroque build system prevents people like me, who are not Boost.Build experts, from contributing to the project. I still have a PR on Boost.Units stalled; it's a one line change, but it requires some knowledge of Boost.Build to integrate a testcase; again it's hindered a trivial but useful contribution to the project. I just want to point out that no matter how wonderful Boost.Build might be in theory, in practice being different from the rest of the word places a practical barrier upon usage of and participation in the development of Boost. And that barrier is a huge one; most of us don't have the time to dedicate to learn yet another build system just for a single project, *but* learning a common tool like CMake which is used in thousands of projects was worth the cost--I get to reuse and extend that knowledge daily using and contributing to dozens of projects. Please don't discount this in your discussions. Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L... . This is what we do in the absence of proper dependency information being provided by Boost, i.e. no pkg-config, cmake config or similar. We hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time of writing. I wrote a custom parser to extract this metadata from the autolink information in the headers, similarly to the above ticket. *We* pay the cost of this significant defect in the Boost project in the form of a high maintenance burden and breakage with every new Boost release. Most projects hardcode the information, but it's fragile and should be unnecessary, and so we took on that burden so that CMake users could use Boost without worrying about the problems. That's why this file is such a huge and over-complicated nightmare. As and when Boost provides proper configuration information, which I would hope the CMake conversion work would provide, we can throw this entire monster in the bin (most CMake Find modules are a couple dozen lines at most; this one is just shy of 2000). Could I also point to the lengths I have to go to to build Boost as part of a larger project: https://github.com/ome/ome-cmake-superbuild/blob/249f06aa633a0feb2bb99c13fc6... - this is a fragile mapping from compiler to the boost-specific toolset name (why does Boost even care? just to put it in the library name, a feature which I always disable because it's largely pointless?) https://github.com/ome/ome-cmake-superbuild/blob/249f06aa633a0feb2bb99c13fc6... - this is a manual patching of the Jamfiles to build with ICU on Windows; the hardcoded naming assumptions are broken. With CMake, FindICU.cmake (which I wrote), would pick up the correct path automatically and avoid the hardcoding https://github.com/ome/ome-cmake-superbuild/blob/249f06aa633a0feb2bb99c13fc6... - we have to configure twice for Unix and Windows - we have to hand-patch the Unix project-config.jam to use the correct toolset https://github.com/ome/ome-cmake-superbuild/blob/249f06aa633a0feb2bb99c13fc6... - building is ridiculously complicated; look at all that stuff being manually set - again duplicated logic for Unix and Windows - the hardcoded assumptions about the names of the zlib and bzip2 libraries don't always hold on Windows (incidentally, the autolink information is also broken--it hardcodes the names and assumes they are built as part of the Boost build, which isn't always true, particularly in larger projects such as this where multiple components depend upon zlib and bzip2 independently of Boost). - the zlib and bzip2 include paths must be the same; it breaks if they differ (a bug in the Jamfile? workaround is to always have them in the same location) - the install paths for the Windows DLLs needs fixing up; they go into the libdir while every other project puts them into the bindir (because they go on the PATH) I hope the above isn't too upsetting or controversial. I wanted to provide some perspective from the point of view of an outsider and end user, and potential contributor, about what things are like from the other side. Boost is a wonderful collection of libraries, but there are some key things which could be improved, and Boost.Build/b2 has I am sorry to say been one of the worst aspects of Boost. End users need to go through some pain to work around defects in Boost.Build, as well as Boost.Build doing things differently to most other build systems. Some might be due to my Boost.Build inexperience, but either way this is what non-experts experience. It makes using Boost unnecessarily painful and difficult. Kind regards, Roger Leigh
On Fri, Jul 21, 2017 at 7:25 AM, Roger Leigh via Boost <boost@lists.boost.org> wrote:
Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L... ... *We* pay the cost of this significant defect in the Boost project in the form of a high maintenance burden and breakage with every new Boost release.
I'm new but I am in agreement that whatever is needed to make this work should be part of Boost not CMake, since Boost has the expertise to produce accurate information. Placing the burden on CMake is clearly not scalable. I propose that the Steering Committee take a break from causing unnecessary drama and instead focus on this one particular use-case. I realize it is not the "Full Monte" but its something (10 year old ticket anyone?) and I think would heal the recently caused divisions. Thanks
Roger Leigh wrote:
Could I point to this trac ticket: https://svn.boost.org/trac10/ticket/1094 (this is about pkg-config support for Boost).
The problem with this ticket is the same today as it was then: you never explained to Vladimir, who appeared willing to implement whatever's needed, how this support needs to work for the --build-type=complete case. You say `pkg-config --libs filesystem`, which one of the six or eight filesystem libs do you want? (Six or eight is before we take into account address-model=32,64 or multiple toolsets.)
On Fri, Jul 21, 2017 at 9:25 AM, Roger Leigh via Boost < boost@lists.boost.org> wrote:
On 2017-07-21 09:30, Paul A. Bristow via Boost wrote:
The mailing list has recently been focussing on just that - the *how*.
The *how* is looking feasible, but the *who* remains entirely unclear.
So the Steering isn't going to happen without an engine of some expert volunteers with enthusiasm and time.
I ask again ... who?
If you would like volunteers to do this, can I sign up to assist? I've been keen on being able to build Boost with CMake for years, but didn't get involved due to not being a core Boost person, just an end user, and also because it looked like there were also a bunch of keen people already working on it. But if you want additional people on board, I'd be happy to contribute in whatever way I can.
Thanks, Roger. I think a reasonable first effort is to suggest one or more concrete ways forward, like Perter Dimov did a couple of weeks ago. He had example CMake code for people to play with and review, and it sounds like you're quite qualified to do the same. There's been a lot of discussion in the last few days about the manner in which all this has been presented. IMO, what we need now is more concrete and technical efforts. Others may disagree. :) [snip] Could I also point to the lengths I have to go to to build Boost as part of
a larger project:
[snip] I've encountered lots of issues along these lines over the years. This sort of thing is why those of us who support CMake are for it.
I hope the above isn't too upsetting or controversial. I wanted to provide some perspective from the point of view of an outsider and end user, and potential contributor, about what things are like from the other side.
I much appreciate this. Zach
On 21/07/2017 16:25, Roger Leigh via Boost wrote:
Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L... . This is what we do in the absence of proper dependency information being provided by Boost, i.e. no pkg-config, cmake config or similar. We hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time of writing. I wrote a custom parser to extract this metadata from the autolink information in the headers, similarly to the above ticket. *We* pay the cost of this significant defect in the Boost project in the form of a high maintenance burden and breakage with every new Boost release. Most projects hardcode the information, but it's fragile and should be unnecessary, and so we took on that burden so that CMake users could use Boost without worrying about the problems. That's why this file is such a huge and over-complicated nightmare. As and when Boost provides proper configuration information, which I would hope the CMake conversion work would provide, we can throw this entire monster in the bin (most CMake Find modules are a couple dozen lines at most; this one is just shy of 2000).
Then this is a different problem from the build system. You hope the new build system will offer a better dependency information for packaging, but if Boost.Build experts are not too annoyed, I think we can get this much much faster than porting to CMake. People using different build systems than CMake could benefit from this, so we're improving the life of the 100% of Boost packagers. So while we are moving to CMake (if that happens because we find enough people to do the work), which can take several Boost releases, we could kindly ask Boost.Build experts to export that information in a compatible way with the most popular packaging systems.
[...]
I hope the above isn't too upsetting or controversial. I wanted to provide some perspective from the point of view of an outsider and end user, and potential contributor, about what things are like from the other side. Boost is a wonderful collection of libraries, but there are some key things which could be improved, and Boost.Build/b2 has I am sorry to say been one of the worst aspects of Boost. End users need to go through some pain to work around defects in Boost.Build, as well as Boost.Build doing things differently to most other build systems. Some might be due to my Boost.Build inexperience, but either way this is what non-experts experience. It makes using Boost unnecessarily painful and difficult.
I think this is a very valuable information. The SC has given a direction, I don't see fixing "annoying" Boost aspects goes against that direction. Best, Ion
Roger Leigh wrote:
This is what we do in the absence of proper dependency information being provided by Boost, i.e. no pkg-config, cmake config or similar. We hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time of writing.
Why didn't you ask here for us to include dependency information into the release? http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do all sorts of dependency reports and I'm actively maintaining it, I've recently even added a cmake-specific output as I needed that to generate the -config files.
Roger Leigh wrote:
This is what we do in the absence of proper dependency information being provided by Boost, i.e. no pkg-config, cmake config or similar. We hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time of writing.
Why didn't you ask here for us to include dependency information into the release?
http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do all sorts of dependency reports and I'm actively maintaining it, I've recently even added a cmake-specific output as I needed that to generate the -config files.
This is a serious question, Roger. I'm not trolling you or something. We obviously can't roll back time so this is water under the bridge, but I'm still interested in your answer. You can be as blunt or explicit as you like. Similarly, the pkg-config one. I'm genuinely interested in how pkg-config support, if we have it, is supposed to handle multiple build variants having been installed. I've already solved that for the cmake -config files, but I'm not sure I see a way for pkg-config to support it.
On 22/07/17 11:47, Peter Dimov via Boost wrote:
Roger Leigh wrote:
This is what we do in the absence of proper dependency information being > provided by Boost, i.e. no pkg-config, cmake config or similar. We > hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time > of writing.
Why didn't you ask here for us to include dependency information into the release?
http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do all sorts of dependency reports and I'm actively maintaining it, I've recently even added a cmake-specific output as I needed that to generate the -config files.
This is a serious question, Roger. I'm not trolling you or something.
We obviously can't roll back time so this is water under the bridge, but I'm still interested in your answer. You can be as blunt or explicit as you like.
Terrible to say, but my memory is failing me, and I can't remember! I'm pretty sure I did look at it, but there was some reason why I didn't find it a match for FindBoost's needs at the time, but I can't recall the specifics. I ended up writing this; it's in a CMake script, so it's a bit verbose: https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Scripts/BoostSc... One thing the script does to is special-case a number of situations where a header of one component is actually a separate component in its own right, mainly related to python, mpi and serialization. It's also special-cases the zlib/bzip2 autolink stuff so we don't use the windows-specific data on other platforms. These might have been part of the reason, but I'm not entirely certain. Again not remembering exactly, but the mappings we have in FindBoost right now are not exactly boost component interdependencies but shared/static library interdependencies only, based on the autolink data. That might also have been part of the reason. I'd expect that with Boost providing per-component configuration files, this could be greatly improved to cover every component irrespective of whether or not it provides a library (or libraries).
Similarly, the pkg-config one. I'm genuinely interested in how pkg-config support, if we have it, is supposed to handle multiple build variants having been installed.
I've already solved that for the cmake -config files, but I'm not sure I see a way for pkg-config to support it.
It's been a while since I looked at this, but my understanding is that it can't by design. You have one variant installed, with a matching set of pkg-config files which point to those libraries. If you need multiple variants, you need to install each variant into a separate prefix and then configure pkg-config (via an environment variable) to search the desired prefix. This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself. Regards, Roger
Roger Leigh wrote:
I ended up writing this; it's in a CMake script, so it's a bit verbose:
https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Scripts/BoostSc...
The problem is that the Boost release doesn't contain libs/*/include, so there's no way for FindBoost to compute the info. You have to run the above on a git clone, and you obviously can't do that before the release is available. But we could have put something like the output of `boostdep --list-dependencies` and `boostdep --list-buildable` in the release, which would have enabled FindBoost.cmake to do an educated guess and try to do its best when faced with a new release instead of failing. It's not possible to include the actual library names in that though - those aren't known until `b2 install` time. Just what boostdep gives, repo/module-level dependencies. Oh well.
If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.
Well you don't have much of a choice, do you. :-) People who are accustomed to b2 supporting multiple configs find themselves expecting it of their build system. :-) CMake has a half-hearted support for multiple configs; it would be interesting if it moves even further in this direction and adds support for --platform in addition to --config.
This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.
I had a feeling this would come up, and as the instigator of this let me explain how/why it happened. A very long time ago, before Boost as it happens, I had a toy C++ regex library, I released it to the world and it got some exposure and feedback. However, I was getting about 1 support request a week from folks who were linking regex built one way to an application built in some binary incompatible way (this is with Visual Studio). Now that's a lot of support requests for a library that had only limited exposure pre-boost, pre-github, and yes, pre-sourceforge too. I dread to think how many support requests it would generate now, had this issue not been solved via name mangling and auto-linking when using Visual Studio. It means it "just works" on a platform that has a multitude of different compiler runtimes, all binary-incompatible with each other. Sorry, but a simple "d" suffix on Windows doesn't even begin to cover the whole heap of pain that results from doing this wrong. { Aside 1: If I were forced kicking and screaming to abandon the name mangling, then mangling the library namespace would mitigate this somewhat, but not enough IMO. Aside 2: If the VS CMake generated files were good enough, then the canonical way of using Boost under Visual Studio would be to reference our project files from your applications solution. Then the libraries your using would always be built with the same options that you're using in your project.... well nearly, this actually requires quite a bit of manual intervention to set the properties of every dependent library the same, plus a fair proportion of VS developers seem not to know how to reference an external library from their IDE anyway :( } In short, I simply can't express how much easier name mangling makes the developers life. I can of course see that on other platforms, this makes no sense at all, and assuming there is "one true version" makes perfect sense. Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com
On Jul 22, 2017, at 7:25 AM, John Maddock via Boost <boost@lists.boost.org> wrote:
This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.
I had a feeling this would come up, and as the instigator of this let me explain how/why it happened.
A very long time ago, before Boost as it happens, I had a toy C++ regex library, I released it to the world and it got some exposure and feedback. However, I was getting about 1 support request a week from folks who were linking regex built one way to an application built in some binary incompatible way (this is with Visual Studio). Now that's a lot of support requests for a library that had only limited exposure pre-boost, pre-github, and yes, pre-sourceforge too. I dread to think how many support requests it would generate now, had this issue not been solved via name mangling and auto-linking when using Visual Studio. It means it "just works" on a platform that has a multitude of different compiler runtimes, all binary-incompatible with each other. Sorry, but a simple "d" suffix on Windows doesn't even begin to cover the whole heap of pain that results from doing this wrong.
Cmake generates checks for 64/32 in the version config files. So that when using `find_package(lib)` it will pick the correct binary if available. Also, I believe it will also distinguish binaries in multi-configation builds like VS which can build both debug and release.
On 7/22/2017 8:10 PM, P F via Boost wrote:
On Jul 22, 2017, at 7:25 AM, John Maddock via Boost <boost@lists.boost.org> wrote:
This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.
I had a feeling this would come up, and as the instigator of this let me explain how/why it happened.
A very long time ago, before Boost as it happens, I had a toy C++ regex library, I released it to the world and it got some exposure and feedback. However, I was getting about 1 support request a week from folks who were linking regex built one way to an application built in some binary incompatible way (this is with Visual Studio). Now that's a lot of support requests for a library that had only limited exposure pre-boost, pre-github, and yes, pre-sourceforge too. I dread to think how many support requests it would generate now, had this issue not been solved via name mangling and auto-linking when using Visual Studio. It means it "just works" on a platform that has a multitude of different compiler runtimes, all binary-incompatible with each other. Sorry, but a simple "d" suffix on Windows doesn't even begin to cover the whole heap of pain that results from doing this wrong.
I am very thankful for your work. When I use b2 to create the complete Boost install output files, I simply have one output directory for all 32-bit and a second directory for all 64-bit files. The Intel and Visual Studio versions, thanks to containing specific Boost release numbers live together without any issues. Has this use case been considered for a Cmake based build?
Cmake generates checks for 64/32 in the version config files. So that when using `find_package(lib)` it will pick the correct binary if available. Also, I believe it will also distinguish binaries in multi-configation builds like VS which can build both debug and release.
For a Cmake output on Windows for both Visual Studio and Intel C++, 32 and 64-bit architectures, would it produce the correct name mangled output files? Would the 'find_package(lib)' have a chance to correctly find the Intel and Visual Studio versions as separate files?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3. Just make sure all target names REGEX cleanly, and generate the target graph sets programmatically. Note that the target name has nothing to do with the output name. That's set by a property in cmake. It does default to the target name however. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.
Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work". Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed. Here are the cmake targets which my quickcpplib tooling autogenerates for AFIO v2 based on inspection of the environment (apologies for the long list in advance): ``` ned@lyta:~/windocs/boostish/afio/build_posix$ make help | sort ... afio-asan ... afio_dl ... afio_dl-asan ... afio_dl-asan-atuple ... afio_dl-asan-coverage_main ... afio_dl-asan-execinfo_win64 ... afio_dl-asan-file_handle_create_close ... afio_dl-asan-file_handle_lock_unlock ... afio_dl-asan-map_handle_create_close ... afio_dl-asan-open_hash_index ... afio_dl-asan-packed_backtrace ... afio_dl-asan-ringbuffer_log ... afio_dl-asan-section_handle_create_close ... afio_dl-asan-shared_fs_mutex ... afio_dl-asan-spinlock_tribool ... afio_dl-asan-test_guard ... afio_dl-asan-test_import ... afio_dl-asan-test_message ... afio_dl-asan-type_traits ... afio_dl--atuple ... afio_dl--coverage_main ... afio_dl--execinfo_win64 ... afio_dl--file_handle_create_close ... afio_dl--file_handle_lock_unlock ... afio_dl--map_handle_create_close ... afio_dl-msan ... afio_dl-msan-atuple ... afio_dl-msan-coverage_main ... afio_dl-msan-execinfo_win64 ... afio_dl-msan-file_handle_create_close ... afio_dl-msan-file_handle_lock_unlock ... afio_dl-msan-map_handle_create_close ... afio_dl-msan-open_hash_index ... afio_dl-msan-packed_backtrace ... afio_dl-msan-ringbuffer_log ... afio_dl-msan-section_handle_create_close ... afio_dl-msan-shared_fs_mutex ... afio_dl-msan-spinlock_tribool ... afio_dl-msan-test_guard ... afio_dl-msan-test_import ... afio_dl-msan-test_message ... afio_dl-msan-type_traits ... afio_dl--open_hash_index ... afio_dl--packed_backtrace ... afio_dl--ringbuffer_log ... afio_dl--section_handle_create_close ... afio_dl--shared_fs_mutex ... afio_dl--spinlock_tribool ... afio_dl--test_guard ... afio_dl--test_import ... afio_dl--test_message ... afio_dl-tsan ... afio_dl-tsan-atuple ... afio_dl-tsan-coverage_main ... afio_dl-tsan-execinfo_win64 ... afio_dl-tsan-file_handle_create_close ... afio_dl-tsan-file_handle_lock_unlock ... afio_dl-tsan-map_handle_create_close ... afio_dl-tsan-open_hash_index ... afio_dl-tsan-packed_backtrace ... afio_dl-tsan-ringbuffer_log ... afio_dl-tsan-section_handle_create_close ... afio_dl-tsan-shared_fs_mutex ... afio_dl-tsan-spinlock_tribool ... afio_dl-tsan-test_guard ... afio_dl-tsan-test_import ... afio_dl-tsan-test_message ... afio_dl-tsan-type_traits ... afio_dl--type_traits ... afio_dl-ubsan ... afio_dl-ubsan-atuple ... afio_dl-ubsan-coverage_main ... afio_dl-ubsan-execinfo_win64 ... afio_dl-ubsan-file_handle_create_close ... afio_dl-ubsan-file_handle_lock_unlock ... afio_dl-ubsan-map_handle_create_close ... afio_dl-ubsan-open_hash_index ... afio_dl-ubsan-packed_backtrace ... afio_dl-ubsan-ringbuffer_log ... afio_dl-ubsan-section_handle_create_close ... afio_dl-ubsan-shared_fs_mutex ... afio_dl-ubsan-spinlock_tribool ... afio_dl-ubsan-test_guard ... afio_dl-ubsan-test_import ... afio_dl-ubsan-test_message ... afio_dl-ubsan-type_traits ... afio_docs ... afio_hl-asan-atuple ... afio_hl-asan-coverage_main ... afio_hl-asan-execinfo_win64 ... afio_hl-asan-file_handle_create_close ... afio_hl-asan-file_handle_lock_unlock ... afio_hl-asan-map_handle_create_close ... afio_hl-asan-open_hash_index ... afio_hl-asan-packed_backtrace ... afio_hl-asan-ringbuffer_log ... afio_hl-asan-section_handle_create_close ... afio_hl-asan-shared_fs_mutex ... afio_hl-asan-spinlock_tribool ... afio_hl-asan-test_guard ... afio_hl-asan-test_import ... afio_hl-asan-test_message ... afio_hl-asan-type_traits ... afio_hl--atuple ... afio_hl--coverage_main ... afio_hl--execinfo_win64 ... afio_hl--file_handle_create_close ... afio_hl--file_handle_lock_unlock ... afio_hl--map_handle_create_close ... afio_hl-msan-atuple ... afio_hl-msan-coverage_main ... afio_hl-msan-execinfo_win64 ... afio_hl-msan-file_handle_create_close ... afio_hl-msan-file_handle_lock_unlock ... afio_hl-msan-map_handle_create_close ... afio_hl-msan-open_hash_index ... afio_hl-msan-packed_backtrace ... afio_hl-msan-ringbuffer_log ... afio_hl-msan-section_handle_create_close ... afio_hl-msan-shared_fs_mutex ... afio_hl-msan-spinlock_tribool ... afio_hl-msan-test_guard ... afio_hl-msan-test_import ... afio_hl-msan-test_message ... afio_hl-msan-type_traits ... afio_hl--open_hash_index ... afio_hl--packed_backtrace ... afio_hl--ringbuffer_log ... afio_hl--section_handle_create_close ... afio_hl--shared_fs_mutex ... afio_hl--spinlock_tribool ... afio_hl--test_guard ... afio_hl--test_import ... afio_hl--test_message ... afio_hl-tsan-atuple ... afio_hl-tsan-coverage_main ... afio_hl-tsan-execinfo_win64 ... afio_hl-tsan-file_handle_create_close ... afio_hl-tsan-file_handle_lock_unlock ... afio_hl-tsan-map_handle_create_close ... afio_hl-tsan-open_hash_index ... afio_hl-tsan-packed_backtrace ... afio_hl-tsan-ringbuffer_log ... afio_hl-tsan-section_handle_create_close ... afio_hl-tsan-shared_fs_mutex ... afio_hl-tsan-spinlock_tribool ... afio_hl-tsan-test_guard ... afio_hl-tsan-test_import ... afio_hl-tsan-test_message ... afio_hl-tsan-type_traits ... afio_hl--type_traits ... afio_hl-ubsan-atuple ... afio_hl-ubsan-coverage_main ... afio_hl-ubsan-execinfo_win64 ... afio_hl-ubsan-file_handle_create_close ... afio_hl-ubsan-file_handle_lock_unlock ... afio_hl-ubsan-map_handle_create_close ... afio_hl-ubsan-open_hash_index ... afio_hl-ubsan-packed_backtrace ... afio_hl-ubsan-ringbuffer_log ... afio_hl-ubsan-section_handle_create_close ... afio_hl-ubsan-shared_fs_mutex ... afio_hl-ubsan-spinlock_tribool ... afio_hl-ubsan-test_guard ... afio_hl-ubsan-test_import ... afio_hl-ubsan-test_message ... afio_hl-ubsan-type_traits ... afio-msan ... afio_sl ... afio_sl-asan ... afio_sl-asan-atuple ... afio_sl-asan-coverage_main ... afio_sl-asan-execinfo_win64 ... afio_sl-asan-file_handle_create_close ... afio_sl-asan-file_handle_lock_unlock ... afio_sl-asan-map_handle_create_close ... afio_sl-asan-open_hash_index ... afio_sl-asan-packed_backtrace ... afio_sl-asan-ringbuffer_log ... afio_sl-asan-section_handle_create_close ... afio_sl-asan-shared_fs_mutex ... afio_sl-asan-spinlock_tribool ... afio_sl-asan-test_guard ... afio_sl-asan-test_import ... afio_sl-asan-test_message ... afio_sl-asan-type_traits ... afio_sl--atuple ... afio_sl--coverage_main ... afio_sl--execinfo_win64 ... afio_sl--file_handle_create_close ... afio_sl--file_handle_lock_unlock ... afio_sl--map_handle_create_close ... afio_sl-msan ... afio_sl-msan-atuple ... afio_sl-msan-coverage_main ... afio_sl-msan-execinfo_win64 ... afio_sl-msan-file_handle_create_close ... afio_sl-msan-file_handle_lock_unlock ... afio_sl-msan-map_handle_create_close ... afio_sl-msan-open_hash_index ... afio_sl-msan-packed_backtrace ... afio_sl-msan-ringbuffer_log ... afio_sl-msan-section_handle_create_close ... afio_sl-msan-shared_fs_mutex ... afio_sl-msan-spinlock_tribool ... afio_sl-msan-test_guard ... afio_sl-msan-test_import ... afio_sl-msan-test_message ... afio_sl-msan-type_traits ... afio_sl--open_hash_index ... afio_sl--packed_backtrace ... afio_sl--ringbuffer_log ... afio_sl--section_handle_create_close ... afio_sl--shared_fs_mutex ... afio_sl--spinlock_tribool ... afio_sl--test_guard ... afio_sl--test_import ... afio_sl--test_message ... afio_sl-tsan ... afio_sl-tsan-atuple ... afio_sl-tsan-coverage_main ... afio_sl-tsan-execinfo_win64 ... afio_sl-tsan-file_handle_create_close ... afio_sl-tsan-file_handle_lock_unlock ... afio_sl-tsan-map_handle_create_close ... afio_sl-tsan-open_hash_index ... afio_sl-tsan-packed_backtrace ... afio_sl-tsan-ringbuffer_log ... afio_sl-tsan-section_handle_create_close ... afio_sl-tsan-shared_fs_mutex ... afio_sl-tsan-spinlock_tribool ... afio_sl-tsan-test_guard ... afio_sl-tsan-test_import ... afio_sl-tsan-test_message ... afio_sl-tsan-type_traits ... afio_sl--type_traits ... afio_sl-ubsan ... afio_sl-ubsan-atuple ... afio_sl-ubsan-coverage_main ... afio_sl-ubsan-execinfo_win64 ... afio_sl-ubsan-file_handle_create_close ... afio_sl-ubsan-file_handle_lock_unlock ... afio_sl-ubsan-map_handle_create_close ... afio_sl-ubsan-open_hash_index ... afio_sl-ubsan-packed_backtrace ... afio_sl-ubsan-ringbuffer_log ... afio_sl-ubsan-section_handle_create_close ... afio_sl-ubsan-shared_fs_mutex ... afio_sl-ubsan-spinlock_tribool ... afio_sl-ubsan-test_guard ... afio_sl-ubsan-test_import ... afio_sl-ubsan-test_message ... afio_sl-ubsan-type_traits ... afio-tsan ... afio-ubsan ... all (the default if no target is provided) ... _asan ... clean ... Continuous ... ContinuousBuild ... ContinuousConfigure ... ContinuousCoverage ... ContinuousMemCheck ... ContinuousStart ... ContinuousSubmit ... ContinuousTest ... ContinuousUpdate ... depend ... _dl ... _docs ... edit_cache ... Experimental ... ExperimentalBuild ... ExperimentalConfigure ... ExperimentalCoverage ... ExperimentalMemCheck ... ExperimentalStart ... ExperimentalSubmit ... ExperimentalTest ... ExperimentalUpdate ... _hl ... install ... install/local ... install/strip ... kerneltest_docs ... list_install_components ... _msan ... Nightly ... NightlyBuild ... NightlyConfigure ... NightlyCoverage ... NightlyMemCheck ... NightlyMemoryCheck ... NightlyStart ... NightlySubmit ... NightlyTest ... NightlyUpdate ... quickcpplib_docs ... rebuild_cache ... _sl The following are some of the valid targets for this Makefile: ... _tsan ... _ubsan ``` The target graphs are REGEXable via the pattern "<lib>_<hl|sl|dl>-<special>-<binary>" where: * hl = header only library * sl = static library * dl = shared library ... and <special> is anything affecting the link requirements of the binary, so here QuickCppLib auto detected the code sanitisers asan,msan,tsan,ubsan all of which require to be linked like-with-like, and hence needed a separate <special> category. Group-level targets also exist, so "afio_sl-tsan" means "all the static library AFIO targets with Thread Sanitiser", "_tsan" means "all the targets with Thread Sanitiser" and so on. Almost the entire graph above is marked with EXCLUDE_FROM_ALL, so it is NOT built unless you specifically request it at the command line. The above is just the mangling for cmake targets which must always be unique within a given cmake build else cmake will refuse to work, hence mangling systematically according to a strict REGEX pattern makes a ton of sense (and using TARGET ALIAS to a more convenient to type target name like "boost::afio"). The actual binaries generated by the build are further mangled again according to this REGEXable pattern: ``` if(CMAKE_GENERATOR MATCHES "Visual Studio") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$<PLATFORM_ID>-$(Platform)-$<CONFIG>" ) elseif(CMAKE_GENERATOR MATCHES "Xcode") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$<PLATFORM_ID>-${CMAKE_SYSTEM_PROCESSOR}-$<CONFIG>" ) else() set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}-${CMAKE_BUILD_TYPE}" ) endif() ``` This will generate library binaries of the pattern: afio_dl-2.0-Linux-x64-Release.so afio_dl-2.0-FreeBSD-x64-MinSizeRel.so afio_dl-2.0-Win32-x86-RelWithDebInfo.dll ... and so on, correctly handling if the user selects different build configs in Visual Studio or XCode which cmake doesn't know anything about. So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.
Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".
Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.
...
So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too.
I'm not necessarily arguing against that approach, but after having heard many (both over the years, and recently) argue that CMake's "one build directory per configuration" philosophy is better than Boost.Build's multiconfig philosophy, it's amusing to see you suggest that idiomatic and modern CMake 3 is a reinvention of Boost.Build. :-)
So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too.
I'm not necessarily arguing against that approach, but after having heard many (both over the years, and recently) argue that CMake's "one build directory per configuration" philosophy is better than Boost.Build's multiconfig philosophy, it's amusing to see you suggest that idiomatic and modern CMake 3 is a reinvention of Boost.Build. :-)
Boost.Build has the correct design. That was and never has been in doubt. We should not throw out the baby with the bathwater in any cmake transition. Cleave as close as is possible to Boost.Build and the existing build and test design. Makes for much less work. Besides, the "one build directory per configuration" really refers to differing compiler versions, differing 32 vs 64 bit, and the other things for which cmake specifically requires a separate build directory each. If cmake doesn't require a separate build directory for something, then use graphs of targets. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 23/07/17 11:42, Niall Douglas via Boost wrote:
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.
Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".
I have to strongly disagree here. It's not about being "broken", it's about being non-standard and overly-complicated for marginal benefit. This pushes an additional burden on end users of Boost to somehow know in advance which bits are encoded in the library names; it's a terrible requirement to impose on others. This forces every end user to provide some mapping from their own build logic to the names used by Boost for encoding each component of the configuration suffix, and then hope that the system provides that. Consider just how costly and painful this truly is. I've suffered from this in the past trying to use Boost with the autotools on Linux. Debian used to use suffixes for single- and multi-threaded. So what do I do, search for the -st and -mt suffixes and also unsuffixed? Or hardcode the one I expect, complicated by the provided names changing over time? I went with the latter, only to have it fail to build on other systems with different names in use, to then try to autodetect all the variants only to still have people complain it still fails because there's some other variant I didn't cater for. And this was just for a single suffix variant. Thankfully, most Linux distributions later dropped all the suffixes. This policy forces every consumer to need to reimplement a good chunk of logic to determine what name might be in use. And I say might, because it's essentially an unrewarding guessing game. And every failure is an example of compromised portability of other people's codebases caused by this policy. One of the reasons I switched to using CMake was that FindBoost.cmake encoded most of the esoteric rules used in the naming conventions and plays the guessing game really well. It usually finds the right answer. But that's ~2000 lines of nastiness which I have to maintain, and the rules keep changing with each Boost release. If you're not using CMake, and you can't hardcode some specific variant, you have to pay some of this cost as well; multiply that by each independent downstream use of Boost. Is that cost acceptable? The suggestion in another post that some of this stuff could be encoded in the pkg-config names is also subject to this problem. It again pushes a burden onto every single consumer of the boost libraries, which in my opinion is quite unacceptable. It also kind of defeats the point of using pkg-config in the first place. It's whole purpose is to answer the simple question: what do I need to compile and link with X, and if that's not handled, it's failed.
Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.
In my experience as an end user of Boost, it only *adds* time, hassle and confusion. I want to link with a specific library, and I don't want this obfuscated unnecessarily.
Here are the cmake targets which my quickcpplib tooling autogenerates for AFIO v2 based on inspection of the environment (apologies for the long list in advance): [...] ... and <special> is anything affecting the link requirements of the binary, so here QuickCppLib auto detected the code sanitisers asan,msan,tsan,ubsan all of which require to be linked like-with-like, and hence needed a separate <special> category.
Group-level targets also exist, so "afio_sl-tsan" means "all the static library AFIO targets with Thread Sanitiser", "_tsan" means "all the targets with Thread Sanitiser" and so on.
The above is just the mangling for cmake targets which must always be unique within a given cmake build else cmake will refuse to work, hence mangling systematically according to a strict REGEX pattern makes a ton of sense (and using TARGET ALIAS to a more convenient to type target name like "boost::afio").
The actual binaries generated by the build are further mangled again according to this REGEXable pattern:
Apologies for saying this, but this is truly horrific. None of that belongs in a CMake build. One of the benefits of using a standard build system, be it the GNU Autotools, CMake, Maven or something else is that they provide standard ways of doing things. This starts with common command-line options and configurable properties, to build targets and behaviour. This makes the build of one project accessible to others for both development and end use because it uses the same conventions that all the other projects using the build system adhere to. That is to say, there are certain basic expectations of what the system will provide and how it will behave. While it's certainly possible with CMake to deviate from the default behaviour, this breaks a whole lot of those expectations, and significantly complicates and devalues what CMake provides for us. The key disagreement here is that there are two ways of doing things: - Running a build and having it produce multiple builds of the same library, with the configuration details encoded in the name, which may be installed alongside each other. You need to know the specific variant name to link with it. - Running a build with a specific configuration and having it product a single library with a plain name; you need to run multiple separate builds with separate install prefixes to build multiple combinations. You don't need to know the variant name to link with it, but you do need to know the path to the variant you want. The former is what Boost.Build provides. The latter is what the GNU Autotools, CMake and pretty much every one else provides. Boost is the exception here. Pretty much every project I've ever come across does the latter. While I can see the reasons why the Boost conventions were established, I don't agree that they are the ideal solution or that they have value for the general case; there is also value in behaving the same as the rest of the world for ease of interoperability and use. For example, I manage just fine for all my work projects by having the automated CI system doing builds for n configuration variants and packaging up artefacts for each of the n variants for Windows, and also for all the other platforms I support. Also, in the Linux world, look at the biarch and multiarch layouts. Here's multiarch on Ubuntu 17.04: /usr/lib/x86_64-linux-gnu/libtiff.so.5.2.5 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 the processor type and system are encoded in the lib path. None of it required any special manging of the library names; I can link with -ltiff or -lboost_filesystem and it will just work. You can also use paths on Windows in exactly the same manner for build variants, again with no name mangling. I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible. Regards, Roger
I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible.
I appreciate everything you've just said and the time you took to say it. But quite frankly, you're plain wrong: 1. The mangling pattern should be published with a formal regex for parsing it. It should never, ever change. 2. cmake lets external cmake override binary naming arbitrarily, so if you really want the binary to be called foo.so, you can go ahead and do that no problem because you know the mangling of the cmake target names, so you know which target sets to set properties for. 3. If you're working outside of cmake, cmake export writes config files which are of stable layout and which can be easily regex scanned for the name of the binary you need. Any bit of scripting can do this, even Windows batch. I've done this countless times, it's a really nice feature of cmake. So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name. Even I who has been at this game twenty plus years now I still accidentally link a binary compiled one way with binaries compiled an incompatible way, and then spent hours - occasionally days - scratching my head as to what is wrong. Indeed it only happened to me again a few days ago where I mixed a clang LLVM compiled binary with a MSVC compiled binary. Bad idea. Name mangling of library outputs is a universal good. It's why Boost does it, and any sane cmake does it. After all, why else has cmake generator expression support for name mangling? And if you're not doing it where you code, with respect I suggest you need a ton load more automated tooling deployed where you work, because you obviously are not doing enough testing or the right testing. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Jul 23, 2017, at 5:23 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible.
I appreciate everything you've just said and the time you took to say it. But quite frankly, you're plain wrong:
1. The mangling pattern should be published with a formal regex for parsing it. It should never, ever change.
2. cmake lets external cmake override binary naming arbitrarily, so if you really want the binary to be called foo.so, you can go ahead and do that no problem because you know the mangling of the cmake target names, so you know which target sets to set properties for.
3. If you're working outside of cmake, cmake export writes config files which are of stable layout and which can be easily regex scanned for the name of the binary you need. Any bit of scripting can do this, even Windows batch. I've done this countless times, it's a really nice feature of cmake.
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of P F via Boost Sent: 24 July 2017 00:40 To: boost@lists.boost.org Cc: P F Subject: Re: [boost] cmake target and binary name mangling
On Jul 23, 2017, at 5:23 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible.
I appreciate everything you've just said and the time you took to say it. But quite frankly, you're plain wrong:
1. The mangling pattern should be published with a formal regex for parsing it. It should never, ever change.
2. cmake lets external cmake override binary naming arbitrarily, so if you really want the binary to be called foo.so, you can go ahead and do that no problem because you know the mangling of the cmake target names, so you know which target sets to set properties for.
3. If you're working outside of cmake, cmake export writes config files which are of stable layout and which can be easily regex scanned for the name of the binary you need. Any bit of scripting can do this, even Windows batch. I've done this countless times, it's a really nice feature of cmake.
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Then why does no linux distro do this?
Because it is Linux, not Microsoft Windows. Different rules apply. This is an endian issue - neither is overwhelming right, but having both is the worst. But that's where we are and it's too late now to get rid of different names now. Anyway, I think encoding the info in the name is a really good idea when the linking process is so stupid that it can't even tell me that I'm trying to link a single with a multithreaded or whatever other of the many possible mistakes.
Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.
Not for me - it would be a crippling change to switch to use separate directories. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.
Different audiences. Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it better-safe-than-sorry. For the same reason, a linux package repo need not go mad mangling library names. They control the build config used end-to-end, and end users are rarely going to combine binaries in accidentally stupid ways. But for developers needing to test just compiled binaries in various combinations and configurations, name mangling is an unalloyed win. As I mentioned, I only just shot myself in the foot with this last week because I wasn't mangling the true compiler compiling the binaries into the library names on Windows. So I'd be entirely happy if staging directory had mangled names, and install directory had unmangled names. If that was felt important. Personally speaking, I think there is more than enough work in a cmake conversion without deliberately making more work for yourself unnecessarily. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 24, 2017 at 2:12 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.
Different audiences.
Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it
How'd you handle Debug vs Release mode on Windows? -- Olaf
On 24/07/2017 13:20, Olaf van der Spek wrote:
On Mon, Jul 24, 2017 at 2:12 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.
Different audiences.
Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it
How'd you handle Debug vs Release mode on Windows?
Well, Windows is an outlier in that you can't safely mix debug and release CRTs. As I mentioned, me personally I'd ship the name mangled versions always. I've found it leads to less surprise. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Am 24.07.2017 um 14:28 schrieb Niall Douglas via Boost:
On 24/07/2017 13:20, Olaf van der Spek wrote:
On Mon, Jul 24, 2017 at 2:12 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Very much true!
As I mentioned, me personally I'd ship the name mangled versions always. I've found it leads to less surprise.
Well, my teammates love it not having to second-guess the supported target configuration of a precompiled binary. Ciao Dani
On Mon, Jul 24, 2017 at 2:28 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
On 24/07/2017 13:20, Olaf van der Spek wrote:
On Mon, Jul 24, 2017 at 2:12 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.
Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.
Different audiences.
Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it
How'd you handle Debug vs Release mode on Windows?
Well, Windows is an outlier in that you can't safely mix debug and release CRTs.
So what do you propose? Not supporting Windows?
As I mentioned, me personally I'd ship the name mangled versions always. I've found it leads to less surprise.
I agree -- Olaf
Niall Douglas wrote:
But for developers needing to test just compiled binaries in various combinations and configurations, name mangling is an unalloyed win. As I mentioned, I only just shot myself in the foot with this last week because I wasn't mangling the true compiler compiling the binaries into the library names on Windows.
FWIW, I was just looking into an issue with an exe compiled with -std=c++11 linking to Boost.System compiled with -std=c++03. Since the class layout of boost::system::error_category was different depending on whether <system_error> was available, this lead to interesting times and baffling stack traces. Of course we don't actually have a b2 feature for -std, so its directory encoding didn't help in this case. (And we don't encode this in the library names either, but that can't be done until we have a feature.) (Into the course of investigating this, I learned that libstdc++ performs quite a bit of heroics to prevent C++11 std::string and C++03 std::string to get mixed up in a similar way, or, if that's not possible, to make it work. So this is not just a Windows issue. It's just that a lot of work is done behind the scenes to keep things from breaking. Kind of like Boost.)
On 24/07/2017 10:23, Niall Douglas wrote:
So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name. Even I who has been at this game twenty plus years now I still accidentally link a binary compiled one way with binaries compiled an incompatible way, and then spent hours - occasionally days - scratching my head as to what is wrong. Indeed it only happened to me again a few days ago where I mixed a clang LLVM compiled binary with a MSVC compiled binary. Bad idea.
Name mangling of library outputs is a universal good. It's why Boost does it, and any sane cmake does it. After all, why else has cmake generator expression support for name mangling? And if you're not doing it where you code, with respect I suggest you need a ton load more automated tooling deployed where you work, because you obviously are not doing enough testing or the right testing.
FWIW, for Windows compiles I use auto-linking, and then have a script examine the import table of the resulting binaries to extract the names of the libraries thus auto-linked-to in order to determine which DLLs need to be included in installation scripts and the like. So it's basically all automatic and I don't really ever need to care what the libraries are called, as long as they *do* have mangled names (and thus alternate versions can co-exist in the same target folder). Linux is actually a little more painful, because it doesn't have auto-linking and none of its auto-naming conventions really fit what's really important. Generally speaking Linux is a bit less picky about linking modules built with different compilers or different versions together -- up to a point, that point being which libc gets linked in. But there isn't an option to mangle the name based on the libc version, just the compiler version.
On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.
Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.
Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".
Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.
Here are the cmake targets which my quickcpplib tooling autogenerates for AFIO v2 based on inspection of the environment (apologies for the long list in advance):
``` ned@lyta:~/windocs/boostish/afio/build_posix$ make help | sort ... afio-asan ... afio_dl ... afio_dl-asan ... afio_dl-asan-atuple ... afio_dl-asan-coverage_main ... afio_dl-asan-execinfo_win64 ... afio_dl-asan-file_handle_create_close ... afio_dl-asan-file_handle_lock_unlock ... afio_dl-asan-map_handle_create_close ... afio_dl-asan-open_hash_index ... afio_dl-asan-packed_backtrace ... afio_dl-asan-ringbuffer_log ... afio_dl-asan-section_handle_create_close ... afio_dl-asan-shared_fs_mutex ... afio_dl-asan-spinlock_tribool ... afio_dl-asan-test_guard ... afio_dl-asan-test_import ... afio_dl-asan-test_message ... afio_dl-asan-type_traits ... afio_dl--atuple ... afio_dl--coverage_main ... afio_dl--execinfo_win64 ... afio_dl--file_handle_create_close ... afio_dl--file_handle_lock_unlock ... afio_dl--map_handle_create_close ... afio_dl-msan ... afio_dl-msan-atuple ... afio_dl-msan-coverage_main ... afio_dl-msan-execinfo_win64 ... afio_dl-msan-file_handle_create_close ... afio_dl-msan-file_handle_lock_unlock ... afio_dl-msan-map_handle_create_close ... afio_dl-msan-open_hash_index ... afio_dl-msan-packed_backtrace ... afio_dl-msan-ringbuffer_log ... afio_dl-msan-section_handle_create_close ... afio_dl-msan-shared_fs_mutex ... afio_dl-msan-spinlock_tribool ... afio_dl-msan-test_guard ... afio_dl-msan-test_import ... afio_dl-msan-test_message ... afio_dl-msan-type_traits ... afio_dl--open_hash_index ... afio_dl--packed_backtrace ... afio_dl--ringbuffer_log ... afio_dl--section_handle_create_close ... afio_dl--shared_fs_mutex ... afio_dl--spinlock_tribool ... afio_dl--test_guard ... afio_dl--test_import ... afio_dl--test_message ... afio_dl-tsan ... afio_dl-tsan-atuple ... afio_dl-tsan-coverage_main ... afio_dl-tsan-execinfo_win64 ... afio_dl-tsan-file_handle_create_close ... afio_dl-tsan-file_handle_lock_unlock ... afio_dl-tsan-map_handle_create_close ... afio_dl-tsan-open_hash_index ... afio_dl-tsan-packed_backtrace ... afio_dl-tsan-ringbuffer_log ... afio_dl-tsan-section_handle_create_close ... afio_dl-tsan-shared_fs_mutex ... afio_dl-tsan-spinlock_tribool ... afio_dl-tsan-test_guard ... afio_dl-tsan-test_import ... afio_dl-tsan-test_message ... afio_dl-tsan-type_traits ... afio_dl--type_traits ... afio_dl-ubsan ... afio_dl-ubsan-atuple ... afio_dl-ubsan-coverage_main ... afio_dl-ubsan-execinfo_win64 ... afio_dl-ubsan-file_handle_create_close ... afio_dl-ubsan-file_handle_lock_unlock ... afio_dl-ubsan-map_handle_create_close ... afio_dl-ubsan-open_hash_index ... afio_dl-ubsan-packed_backtrace ... afio_dl-ubsan-ringbuffer_log ... afio_dl-ubsan-section_handle_create_close ... afio_dl-ubsan-shared_fs_mutex ... afio_dl-ubsan-spinlock_tribool ... afio_dl-ubsan-test_guard ... afio_dl-ubsan-test_import ... afio_dl-ubsan-test_message ... afio_dl-ubsan-type_traits ... afio_docs ... afio_hl-asan-atuple ... afio_hl-asan-coverage_main ... afio_hl-asan-execinfo_win64 ... afio_hl-asan-file_handle_create_close ... afio_hl-asan-file_handle_lock_unlock ... afio_hl-asan-map_handle_create_close ... afio_hl-asan-open_hash_index ... afio_hl-asan-packed_backtrace ... afio_hl-asan-ringbuffer_log ... afio_hl-asan-section_handle_create_close ... afio_hl-asan-shared_fs_mutex ... afio_hl-asan-spinlock_tribool ... afio_hl-asan-test_guard ... afio_hl-asan-test_import ... afio_hl-asan-test_message ... afio_hl-asan-type_traits ... afio_hl--atuple ... afio_hl--coverage_main ... afio_hl--execinfo_win64 ... afio_hl--file_handle_create_close ... afio_hl--file_handle_lock_unlock ... afio_hl--map_handle_create_close ... afio_hl-msan-atuple ... afio_hl-msan-coverage_main ... afio_hl-msan-execinfo_win64 ... afio_hl-msan-file_handle_create_close ... afio_hl-msan-file_handle_lock_unlock ... afio_hl-msan-map_handle_create_close ... afio_hl-msan-open_hash_index ... afio_hl-msan-packed_backtrace ... afio_hl-msan-ringbuffer_log ... afio_hl-msan-section_handle_create_close ... afio_hl-msan-shared_fs_mutex ... afio_hl-msan-spinlock_tribool ... afio_hl-msan-test_guard ... afio_hl-msan-test_import ... afio_hl-msan-test_message ... afio_hl-msan-type_traits ... afio_hl--open_hash_index ... afio_hl--packed_backtrace ... afio_hl--ringbuffer_log ... afio_hl--section_handle_create_close ... afio_hl--shared_fs_mutex ... afio_hl--spinlock_tribool ... afio_hl--test_guard ... afio_hl--test_import ... afio_hl--test_message ... afio_hl-tsan-atuple ... afio_hl-tsan-coverage_main ... afio_hl-tsan-execinfo_win64 ... afio_hl-tsan-file_handle_create_close ... afio_hl-tsan-file_handle_lock_unlock ... afio_hl-tsan-map_handle_create_close ... afio_hl-tsan-open_hash_index ... afio_hl-tsan-packed_backtrace ... afio_hl-tsan-ringbuffer_log ... afio_hl-tsan-section_handle_create_close ... afio_hl-tsan-shared_fs_mutex ... afio_hl-tsan-spinlock_tribool ... afio_hl-tsan-test_guard ... afio_hl-tsan-test_import ... afio_hl-tsan-test_message ... afio_hl-tsan-type_traits ... afio_hl--type_traits ... afio_hl-ubsan-atuple ... afio_hl-ubsan-coverage_main ... afio_hl-ubsan-execinfo_win64 ... afio_hl-ubsan-file_handle_create_close ... afio_hl-ubsan-file_handle_lock_unlock ... afio_hl-ubsan-map_handle_create_close ... afio_hl-ubsan-open_hash_index ... afio_hl-ubsan-packed_backtrace ... afio_hl-ubsan-ringbuffer_log ... afio_hl-ubsan-section_handle_create_close ... afio_hl-ubsan-shared_fs_mutex ... afio_hl-ubsan-spinlock_tribool ... afio_hl-ubsan-test_guard ... afio_hl-ubsan-test_import ... afio_hl-ubsan-test_message ... afio_hl-ubsan-type_traits ... afio-msan ... afio_sl ... afio_sl-asan ... afio_sl-asan-atuple ... afio_sl-asan-coverage_main ... afio_sl-asan-execinfo_win64 ... afio_sl-asan-file_handle_create_close ... afio_sl-asan-file_handle_lock_unlock ... afio_sl-asan-map_handle_create_close ... afio_sl-asan-open_hash_index ... afio_sl-asan-packed_backtrace ... afio_sl-asan-ringbuffer_log ... afio_sl-asan-section_handle_create_close ... afio_sl-asan-shared_fs_mutex ... afio_sl-asan-spinlock_tribool ... afio_sl-asan-test_guard ... afio_sl-asan-test_import ... afio_sl-asan-test_message ... afio_sl-asan-type_traits ... afio_sl--atuple ... afio_sl--coverage_main ... afio_sl--execinfo_win64 ... afio_sl--file_handle_create_close ... afio_sl--file_handle_lock_unlock ... afio_sl--map_handle_create_close ... afio_sl-msan ... afio_sl-msan-atuple ... afio_sl-msan-coverage_main ... afio_sl-msan-execinfo_win64 ... afio_sl-msan-file_handle_create_close ... afio_sl-msan-file_handle_lock_unlock ... afio_sl-msan-map_handle_create_close ... afio_sl-msan-open_hash_index ... afio_sl-msan-packed_backtrace ... afio_sl-msan-ringbuffer_log ... afio_sl-msan-section_handle_create_close ... afio_sl-msan-shared_fs_mutex ... afio_sl-msan-spinlock_tribool ... afio_sl-msan-test_guard ... afio_sl-msan-test_import ... afio_sl-msan-test_message ... afio_sl-msan-type_traits ... afio_sl--open_hash_index ... afio_sl--packed_backtrace ... afio_sl--ringbuffer_log ... afio_sl--section_handle_create_close ... afio_sl--shared_fs_mutex ... afio_sl--spinlock_tribool ... afio_sl--test_guard ... afio_sl--test_import ... afio_sl--test_message ... afio_sl-tsan ... afio_sl-tsan-atuple ... afio_sl-tsan-coverage_main ... afio_sl-tsan-execinfo_win64 ... afio_sl-tsan-file_handle_create_close ... afio_sl-tsan-file_handle_lock_unlock ... afio_sl-tsan-map_handle_create_close ... afio_sl-tsan-open_hash_index ... afio_sl-tsan-packed_backtrace ... afio_sl-tsan-ringbuffer_log ... afio_sl-tsan-section_handle_create_close ... afio_sl-tsan-shared_fs_mutex ... afio_sl-tsan-spinlock_tribool ... afio_sl-tsan-test_guard ... afio_sl-tsan-test_import ... afio_sl-tsan-test_message ... afio_sl-tsan-type_traits ... afio_sl--type_traits ... afio_sl-ubsan ... afio_sl-ubsan-atuple ... afio_sl-ubsan-coverage_main ... afio_sl-ubsan-execinfo_win64 ... afio_sl-ubsan-file_handle_create_close ... afio_sl-ubsan-file_handle_lock_unlock ... afio_sl-ubsan-map_handle_create_close ... afio_sl-ubsan-open_hash_index ... afio_sl-ubsan-packed_backtrace ... afio_sl-ubsan-ringbuffer_log ... afio_sl-ubsan-section_handle_create_close ... afio_sl-ubsan-shared_fs_mutex ... afio_sl-ubsan-spinlock_tribool ... afio_sl-ubsan-test_guard ... afio_sl-ubsan-test_import ... afio_sl-ubsan-test_message ... afio_sl-ubsan-type_traits ... afio-tsan ... afio-ubsan ... all (the default if no target is provided) ... _asan ... clean ... Continuous ... ContinuousBuild ... ContinuousConfigure ... ContinuousCoverage ... ContinuousMemCheck ... ContinuousStart ... ContinuousSubmit ... ContinuousTest ... ContinuousUpdate ... depend ... _dl ... _docs ... edit_cache ... Experimental ... ExperimentalBuild ... ExperimentalConfigure ... ExperimentalCoverage ... ExperimentalMemCheck ... ExperimentalStart ... ExperimentalSubmit ... ExperimentalTest ... ExperimentalUpdate ... _hl ... install ... install/local ... install/strip ... kerneltest_docs ... list_install_components ... _msan ... Nightly ... NightlyBuild ... NightlyConfigure ... NightlyCoverage ... NightlyMemCheck ... NightlyMemoryCheck ... NightlyStart ... NightlySubmit ... NightlyTest ... NightlyUpdate ... quickcpplib_docs ... rebuild_cache ... _sl The following are some of the valid targets for this Makefile: ... _tsan ... _ubsan ```
The target graphs are REGEXable via the pattern "<lib>_<hl|sl|dl>-<special>-<binary>" where:
* hl = header only library * sl = static library * dl = shared library
There is no need for `hl` as it doesn’t produce binaries.
... and <special> is anything affecting the link requirements of the binary, so here QuickCppLib auto detected the code sanitisers asan,msan,tsan,ubsan all of which require to be linked like-with-like, and hence needed a separate <special> category.
Group-level targets also exist, so "afio_sl-tsan" means "all the static library AFIO targets with Thread Sanitiser", "_tsan" means "all the targets with Thread Sanitiser" and so on.
Almost the entire graph above is marked with EXCLUDE_FROM_ALL, so it is NOT built unless you specifically request it at the command line.
The above is just the mangling for cmake targets which must always be unique within a given cmake build else cmake will refuse to work, hence mangling systematically according to a strict REGEX pattern makes a ton of sense (and using TARGET ALIAS to a more convenient to type target name like "boost::afio").
The actual binaries generated by the build are further mangled again according to this REGEXable pattern:
``` if(CMAKE_GENERATOR MATCHES "Visual Studio") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$<PLATFORM_ID>-$(Platform)-$<CONFIG>" ) elseif(CMAKE_GENERATOR MATCHES "Xcode") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$<PLATFORM_ID>-${CMAKE_SYSTEM_PROCESSOR}-$<CONFIG>" ) else() set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}-${CMAKE_BUILD_TYPE}" ) endif() ```
We could definitely encode this information from the build into the name, but it should be an option like it is now. Perhaps when building with `-DLAYOUT=tagged` will get this behavior. Of course, all this will require custom functions from our own cmake module to make sure this is consistent across boost libraries.
This will generate library binaries of the pattern:
afio_dl-2.0-Linux-x64-Release.so afio_dl-2.0-FreeBSD-x64-MinSizeRel.so afio_dl-2.0-Win32-x86-RelWithDebInfo.dll
... and so on, correctly handling if the user selects different build configs in Visual Studio or XCode which cmake doesn't know anything about.
Only when you link against the library using this pattern, which is really only necessary when not using cmake.
So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too.
The issue isn’t that we encode build information into the name. Its that cmake doesn’t handle multiple variants in the same build tree, like what boost build does. Cmake could support this as it supports multiple configurations with IDEs like VS or XCode. This could be extended to all build systems. Until then, I think building a frontend for cmake that can automate the multiple build trees would be useful to users of b2.
On 24/07/2017 01:19, P F via Boost wrote:
On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3. Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is. Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".
Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.
Here are the cmake targets which my quickcpplib tooling autogenerates for AFIO v2 based on inspection of the environment (apologies for the long list in advance):
``` ned@lyta:~/windocs/boostish/afio/build_posix$ make help | sort ... afio-asan ... afio_dl ... afio_dl-asan ... afio_dl-asan-atuple ... afio_dl-asan-coverage_main ... afio_dl-asan-execinfo_win64 ... afio_dl-asan-file_handle_create_close ... afio_dl-asan-file_handle_lock_unlock ... afio_dl-asan-map_handle_create_close ... afio_dl-asan-open_hash_index ... afio_dl-asan-packed_backtrace ... afio_dl-asan-ringbuffer_log ... afio_dl-asan-section_handle_create_close ... afio_dl-asan-shared_fs_mutex ... afio_dl-asan-spinlock_tribool ... afio_dl-asan-test_guard ... afio_dl-asan-test_import ... afio_dl-asan-test_message ... afio_dl-asan-type_traits ... afio_dl--atuple ... afio_dl--coverage_main ... afio_dl--execinfo_win64 ... afio_dl--file_handle_create_close ... afio_dl--file_handle_lock_unlock ... afio_dl--map_handle_create_close ... afio_dl-msan ... afio_dl-msan-atuple ... afio_dl-msan-coverage_main ... afio_dl-msan-execinfo_win64 ... afio_dl-msan-file_handle_create_close ... afio_dl-msan-file_handle_lock_unlock ... afio_dl-msan-map_handle_create_close ... afio_dl-msan-open_hash_index ... afio_dl-msan-packed_backtrace ... afio_dl-msan-ringbuffer_log ... afio_dl-msan-section_handle_create_close ... afio_dl-msan-shared_fs_mutex ... afio_dl-msan-spinlock_tribool ... afio_dl-msan-test_guard ... afio_dl-msan-test_import ... afio_dl-msan-test_message ... afio_dl-msan-type_traits ... afio_dl--open_hash_index ... afio_dl--packed_backtrace ... afio_dl--ringbuffer_log ... afio_dl--section_handle_create_close ... afio_dl--shared_fs_mutex ... afio_dl--spinlock_tribool ... afio_dl--test_guard ... afio_dl--test_import ... afio_dl--test_message ... afio_dl-tsan ... afio_dl-tsan-atuple ... afio_dl-tsan-coverage_main ... afio_dl-tsan-execinfo_win64 ... afio_dl-tsan-file_handle_create_close ... afio_dl-tsan-file_handle_lock_unlock ... afio_dl-tsan-map_handle_create_close ... afio_dl-tsan-open_hash_index ... afio_dl-tsan-packed_backtrace ... afio_dl-tsan-ringbuffer_log ... afio_dl-tsan-section_handle_create_close ... afio_dl-tsan-shared_fs_mutex ... afio_dl-tsan-spinlock_tribool ... afio_dl-tsan-test_guard ... afio_dl-tsan-test_import ... afio_dl-tsan-test_message ... afio_dl-tsan-type_traits ... afio_dl--type_traits ... afio_dl-ubsan ... afio_dl-ubsan-atuple ... afio_dl-ubsan-coverage_main ... afio_dl-ubsan-execinfo_win64 ... afio_dl-ubsan-file_handle_create_close ... afio_dl-ubsan-file_handle_lock_unlock ... afio_dl-ubsan-map_handle_create_close ... afio_dl-ubsan-open_hash_index ... afio_dl-ubsan-packed_backtrace ... afio_dl-ubsan-ringbuffer_log ... afio_dl-ubsan-section_handle_create_close ... afio_dl-ubsan-shared_fs_mutex ... afio_dl-ubsan-spinlock_tribool ... afio_dl-ubsan-test_guard ... afio_dl-ubsan-test_import ... afio_dl-ubsan-test_message ... afio_dl-ubsan-type_traits ... afio_docs ... afio_hl-asan-atuple ... afio_hl-asan-coverage_main ... afio_hl-asan-execinfo_win64 ... afio_hl-asan-file_handle_create_close ... afio_hl-asan-file_handle_lock_unlock ... afio_hl-asan-map_handle_create_close ... afio_hl-asan-open_hash_index ... afio_hl-asan-packed_backtrace ... afio_hl-asan-ringbuffer_log ... afio_hl-asan-section_handle_create_close ... afio_hl-asan-shared_fs_mutex ... afio_hl-asan-spinlock_tribool ... afio_hl-asan-test_guard ... afio_hl-asan-test_import ... afio_hl-asan-test_message ... afio_hl-asan-type_traits ... afio_hl--atuple ... afio_hl--coverage_main ... afio_hl--execinfo_win64 ... afio_hl--file_handle_create_close ... afio_hl--file_handle_lock_unlock ... afio_hl--map_handle_create_close ... afio_hl-msan-atuple ... afio_hl-msan-coverage_main ... afio_hl-msan-execinfo_win64 ... afio_hl-msan-file_handle_create_close ... afio_hl-msan-file_handle_lock_unlock ... afio_hl-msan-map_handle_create_close ... afio_hl-msan-open_hash_index ... afio_hl-msan-packed_backtrace ... afio_hl-msan-ringbuffer_log ... afio_hl-msan-section_handle_create_close ... afio_hl-msan-shared_fs_mutex ... afio_hl-msan-spinlock_tribool ... afio_hl-msan-test_guard ... afio_hl-msan-test_import ... afio_hl-msan-test_message ... afio_hl-msan-type_traits ... afio_hl--open_hash_index ... afio_hl--packed_backtrace ... afio_hl--ringbuffer_log ... afio_hl--section_handle_create_close ... afio_hl--shared_fs_mutex ... afio_hl--spinlock_tribool ... afio_hl--test_guard ... afio_hl--test_import ... afio_hl--test_message ... afio_hl-tsan-atuple ... afio_hl-tsan-coverage_main ... afio_hl-tsan-execinfo_win64 ... afio_hl-tsan-file_handle_create_close ... afio_hl-tsan-file_handle_lock_unlock ... afio_hl-tsan-map_handle_create_close ... afio_hl-tsan-open_hash_index ... afio_hl-tsan-packed_backtrace ... afio_hl-tsan-ringbuffer_log ... afio_hl-tsan-section_handle_create_close ... afio_hl-tsan-shared_fs_mutex ... afio_hl-tsan-spinlock_tribool ... afio_hl-tsan-test_guard ... afio_hl-tsan-test_import ... afio_hl-tsan-test_message ... afio_hl-tsan-type_traits ... afio_hl--type_traits ... afio_hl-ubsan-atuple ... afio_hl-ubsan-coverage_main ... afio_hl-ubsan-execinfo_win64 ... afio_hl-ubsan-file_handle_create_close ... afio_hl-ubsan-file_handle_lock_unlock ... afio_hl-ubsan-map_handle_create_close ... afio_hl-ubsan-open_hash_index ... afio_hl-ubsan-packed_backtrace ... afio_hl-ubsan-ringbuffer_log ... afio_hl-ubsan-section_handle_create_close ... afio_hl-ubsan-shared_fs_mutex ... afio_hl-ubsan-spinlock_tribool ... afio_hl-ubsan-test_guard ... afio_hl-ubsan-test_import ... afio_hl-ubsan-test_message ... afio_hl-ubsan-type_traits ... afio-msan ... afio_sl ... afio_sl-asan ... afio_sl-asan-atuple ... afio_sl-asan-coverage_main ... afio_sl-asan-execinfo_win64 ... afio_sl-asan-file_handle_create_close ... afio_sl-asan-file_handle_lock_unlock ... afio_sl-asan-map_handle_create_close ... afio_sl-asan-open_hash_index ... afio_sl-asan-packed_backtrace ... afio_sl-asan-ringbuffer_log ... afio_sl-asan-section_handle_create_close ... afio_sl-asan-shared_fs_mutex ... afio_sl-asan-spinlock_tribool ... afio_sl-asan-test_guard ... afio_sl-asan-test_import ... afio_sl-asan-test_message ... afio_sl-asan-type_traits ... afio_sl--atuple ... afio_sl--coverage_main ... afio_sl--execinfo_win64 ... afio_sl--file_handle_create_close ... afio_sl--file_handle_lock_unlock ... afio_sl--map_handle_create_close ... afio_sl-msan ... afio_sl-msan-atuple ... afio_sl-msan-coverage_main ... afio_sl-msan-execinfo_win64 ... afio_sl-msan-file_handle_create_close ... afio_sl-msan-file_handle_lock_unlock ... afio_sl-msan-map_handle_create_close ... afio_sl-msan-open_hash_index ... afio_sl-msan-packed_backtrace ... afio_sl-msan-ringbuffer_log ... afio_sl-msan-section_handle_create_close ... afio_sl-msan-shared_fs_mutex ... afio_sl-msan-spinlock_tribool ... afio_sl-msan-test_guard ... afio_sl-msan-test_import ... afio_sl-msan-test_message ... afio_sl-msan-type_traits ... afio_sl--open_hash_index ... afio_sl--packed_backtrace ... afio_sl--ringbuffer_log ... afio_sl--section_handle_create_close ... afio_sl--shared_fs_mutex ... afio_sl--spinlock_tribool ... afio_sl--test_guard ... afio_sl--test_import ... afio_sl--test_message ... afio_sl-tsan ... afio_sl-tsan-atuple ... afio_sl-tsan-coverage_main ... afio_sl-tsan-execinfo_win64 ... afio_sl-tsan-file_handle_create_close ... afio_sl-tsan-file_handle_lock_unlock ... afio_sl-tsan-map_handle_create_close ... afio_sl-tsan-open_hash_index ... afio_sl-tsan-packed_backtrace ... afio_sl-tsan-ringbuffer_log ... afio_sl-tsan-section_handle_create_close ... afio_sl-tsan-shared_fs_mutex ... afio_sl-tsan-spinlock_tribool ... afio_sl-tsan-test_guard ... afio_sl-tsan-test_import ... afio_sl-tsan-test_message ... afio_sl-tsan-type_traits ... afio_sl--type_traits ... afio_sl-ubsan ... afio_sl-ubsan-atuple ... afio_sl-ubsan-coverage_main ... afio_sl-ubsan-execinfo_win64 ... afio_sl-ubsan-file_handle_create_close ... afio_sl-ubsan-file_handle_lock_unlock ... afio_sl-ubsan-map_handle_create_close ... afio_sl-ubsan-open_hash_index ... afio_sl-ubsan-packed_backtrace ... afio_sl-ubsan-ringbuffer_log ... afio_sl-ubsan-section_handle_create_close ... afio_sl-ubsan-shared_fs_mutex ... afio_sl-ubsan-spinlock_tribool ... afio_sl-ubsan-test_guard ... afio_sl-ubsan-test_import ... afio_sl-ubsan-test_message ... afio_sl-ubsan-type_traits ... afio-tsan ... afio-ubsan ... all (the default if no target is provided) ... _asan ... clean ... Continuous ... ContinuousBuild ... ContinuousConfigure ... ContinuousCoverage ... ContinuousMemCheck ... ContinuousStart ... ContinuousSubmit ... ContinuousTest ... ContinuousUpdate ... depend ... _dl ... _docs ... edit_cache ... Experimental ... ExperimentalBuild ... ExperimentalConfigure ... ExperimentalCoverage ... ExperimentalMemCheck ... ExperimentalStart ... ExperimentalSubmit ... ExperimentalTest ... ExperimentalUpdate ... _hl ... install ... install/local ... install/strip ... kerneltest_docs ... list_install_components ... _msan ... Nightly ... NightlyBuild ... NightlyConfigure ... NightlyCoverage ... NightlyMemCheck ... NightlyMemoryCheck ... NightlyStart ... NightlySubmit ... NightlyTest ... NightlyUpdate ... quickcpplib_docs ... rebuild_cache ... _sl The following are some of the valid targets for this Makefile: ... _tsan ... _ubsan ```
The target graphs are REGEXable via the pattern "<lib>_<hl|sl|dl>-<special>-<binary>" where:
* hl = header only library * sl = static library * dl = shared library There is no need for `hl` as it doesn’t produce binaries.
"hl" is necessary as a CMake logical target, not at as a build output. The problem I have with all those targets, is that they add a lot of overload to IDE solutions who will scan sources for every configuration and for people whose workflow is to build "all" or the whole solution for MSVC, which will build way too many versions.
... and <special> is anything affecting the link requirements of the binary, so here QuickCppLib auto detected the code sanitisers asan,msan,tsan,ubsan all of which require to be linked like-with-like, and hence needed a separate <special> category.
Group-level targets also exist, so "afio_sl-tsan" means "all the static library AFIO targets with Thread Sanitiser", "_tsan" means "all the targets with Thread Sanitiser" and so on.
Almost the entire graph above is marked with EXCLUDE_FROM_ALL, so it is NOT built unless you specifically request it at the command line.
The above is just the mangling for cmake targets which must always be unique within a given cmake build else cmake will refuse to work, hence mangling systematically according to a strict REGEX pattern makes a ton of sense (and using TARGET ALIAS to a more convenient to type target name like "boost::afio").
The actual binaries generated by the build are further mangled again according to this REGEXable pattern:
``` if(CMAKE_GENERATOR MATCHES "Visual Studio") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$<PLATFORM_ID>-$(Platform)-$<CONFIG>" ) elseif(CMAKE_GENERATOR MATCHES "Xcode") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$<PLATFORM_ID>-${CMAKE_SYSTEM_PROCESSOR}-$<CONFIG>" ) else() set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}-${CMAKE_BUILD_TYPE}" ) endif() ``` We could definitely encode this information from the build into the name, but it should be an option like it is now. Perhaps when building with `-DLAYOUT=tagged` will get this behavior. Of course, all this will require custom functions from our own cmake module to make sure this is consistent across boost libraries.
I think this is the proper middle ground between both approaches and should totally be doable. In order to reduce boilerplate across all libraries, some common support code needs to be added anyway. As for which one should be default, that's I guess another whole discussion (which is kind of moot when using "add_subdirectory()" integration for example). Though, I disagree with the example above, there's no need to separate all the platforms. The Visual Studio generators don't support multiple archs (Intel 32, 64 and ARM) together, so no "$(Platform)" needed. On Darwin, CMAKE_SYSTEM_PROCESSOR is a bit unreliable too if you consider universal builds on the platforms (ppc + i386 + x86_64). For other generators, you should use the generator expressions too.
This will generate library binaries of the pattern:
afio_dl-2.0-Linux-x64-Release.so afio_dl-2.0-FreeBSD-x64-MinSizeRel.so afio_dl-2.0-Win32-x86-RelWithDebInfo.dll
... and so on, correctly handling if the user selects different build configs in Visual Studio or XCode which cmake doesn't know anything about. Only when you link against the library using this pattern, which is really only necessary when not using cmake.
So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too. The issue isn’t that we encode build information into the name. Its that cmake doesn’t handle multiple variants in the same build tree, like what boost build does. Cmake could support this as it supports multiple configurations with IDEs like VS or XCode. This could be extended to all build systems. Until then, I think building a frontend for cmake that can automate the multiple build trees would be useful to users of b2.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ned@lyta:~/windocs/boostish/afio/build_posix$ make help | sort ... afio-asan ... afio_dl ... afio_dl-asan ... afio_dl-asan-atuple ...
Can everyone please refrain from quoting the whole list of targets; while immensely valuable information, it still ensures that whatever you write after that will remain unread by most. (A phenomenon known as TL;DR.)
The target graphs are REGEXable via the pattern "<lib>_<hl|sl|dl>-<special>-<binary>" where:
* hl = header only library * sl = static library * dl = shared library There is no need for `hl` as it doesn’t produce binaries.
"hl" is necessary as a CMake logical target, not at as a build output.
Indeed. Paul seems to have a mental block regarding header only cmake targeting.
The problem I have with all those targets, is that they add a lot of overload to IDE solutions who will scan sources for every configuration and for people whose workflow is to build "all" or the whole solution for MSVC, which will build way too many versions.
You are correct - if the end user loads the base .vcxproj file. But be aware that consuming cmake projects will link against only the dependent targets that they use, and if you load those .vcxprojs they consist exactly of the minimum subset of targets used. So consider the base library level .vcxproj as a "database". For example, if I open a .vcxproj for an individual unit test, I will get only the minimum target set for that unit test to compile. You'd do the same thing for a release building project. It would bring in only the targets for doing a release distro. Users ought to open that one instead, and we can hide the base "database" .vcxproj file inside a subdirectory. You might now say why bother with a master "database" .vcxproj file then? A single file eases much of the remaining build scripting without needed to use custom cmake function logic, which I strongly recommend against, but am absolutely sure we will see proliferate with all the usual bad consequences in the Boost conversion (c.f. Paul's library of custom cmake function logic he's pushing). But it is true that as the database gets bigger, cmake takes longer to generate it, and eventually a tradeoff needs to be made. That said, cmake 3.9 got a lot faster at generating huge lists of target permutations into a single solution, and I expect that trend will continue as big cmake users like Google push harder on that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 24/07/2017 14:27, Niall Douglas via Boost wrote:
The target graphs are REGEXable via the pattern "<lib>_<hl|sl|dl>-<special>-<binary>" where:
* hl = header only library * sl = static library * dl = shared library There is no need for `hl` as it doesn’t produce binaries. "hl" is necessary as a CMake logical target, not at as a build output. Indeed. Paul seems to have a mental block regarding header only cmake targeting.
The problem I have with all those targets, is that they add a lot of overload to IDE solutions who will scan sources for every configuration and for people whose workflow is to build "all" or the whole solution for MSVC, which will build way too many versions. You are correct - if the end user loads the base .vcxproj file.
But be aware that consuming cmake projects will link against only the dependent targets that they use, and if you load those .vcxprojs they consist exactly of the minimum subset of targets used.
Well, that's true for people who don't rely on the CMake-generated solution files, those will include all the vcxproj files that exist. Then, you could argue that they can use the new fast solution loading, but I don't think it is quite production ready right now (and also, only available in VS2017). For the build times, you could say that people should not build the full solution too and build the right target they actually intend to build, and I would totally agree with that statement. Unfortunately, most people don't work like this and this would be shifting too much of a burden on users.
So consider the base library level .vcxproj as a "database". For example, if I open a .vcxproj for an individual unit test, I will get only the minimum target set for that unit test to compile.
You'd do the same thing for a release building project. It would bring in only the targets for doing a release distro. Users ought to open that one instead, and we can hide the base "database" .vcxproj file inside a subdirectory.
You might now say why bother with a master "database" .vcxproj file then? A single file eases much of the remaining build scripting without needed to use custom cmake function logic, which I strongly recommend against, but am absolutely sure we will see proliferate with all the usual bad consequences in the Boost conversion (c.f. Paul's library of custom cmake function logic he's pushing). But it is true that as the database gets bigger, cmake takes longer to generate it, and eventually a tradeoff needs to be made.
This is kind of tree in a superbuild configuration, but even in this situation, I wouldn't mix my sanitizer enabled binaries with others. It is semantically wrong to mix and match those and you will end up with false positives just like I did at my company when we mixed ASan tests with non-ASan Boost.Test. False positives shown up in the code that built the string holding the name of the test, even though most of people think this is safe to do. Because of those issues, why would just make ASan, TSan, MSan (and others) targets available to link with the rest of the regular targets? Either everything is instrumented (with the same options) or nothing is. To have sanitizer enabled binaries, the traditional solution is just to rebuild it just like another platform, using either a dedicated toolchain file or some light CMake options for the toolchain or eventually main project, which would limit the number of toolchain files to manage. Don't get me wrong, I'm not against having necessarily multiple flavors of libraries like hl/sl/dl even though I think this is superfluous (there should be an option to get whole Boost preferred dynamic, static or header only with only one target name), I'm against the extensive list of targets with all flavors. Those are probably better handled with various CMake configurations, you could have Debug, Release and ASan. Unfortunately, it just clashes with how people use them in general and would make it impractical for lots of users.
That said, cmake 3.9 got a lot faster at generating huge lists of target permutations into a single solution, and I expect that trend will continue as big cmake users like Google push harder on that.
Sure, CMake is faster, but do you think the actual build tools will keep up with this change? They are the ones actually checking for all the source files and other intermediate files. A combinatory proliferation of targets, is not a good thing for them.
Niall
Florent
On Mon, 2017-07-24 at 12:42 +0200, Florent Castelli via Boost wrote:
On 24/07/2017 01:19, P F via Boost wrote:
On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost <boost@lists.boost. org> wrote:
The target graphs are REGEXable via the pattern "<lib>_<hl|sl|dl>-<special>-<binary>" where:
* hl = header only library * sl = static library * dl = shared library
There is no need for `hl` as it doesn’t produce binaries.
"hl" is necessary as a CMake logical target, not at as a build output. The problem I have with all those targets, is that they add a lot of overload to IDE solutions who will scan sources for every configuration and for people whose workflow is to build "all" or the whole solution for MSVC, which will build way too many versions.
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.
paul wrote:
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only.
As we already discussed, sl/dl/hl have the problem that when a non-header-only library links to a header-only one which in turn links to a non-header-only one, the sl/dl of the first one should propagate to the third, which is problematic if the second has to be -hl. The way this works in Boost.Build is that the user indeed writes the equivalent of the above, and then the link=static property is propagated to the dependencies. If there's a library that has an optional header-only mode, this is not encoded as link=header, but as define=BOOST_BAR_HEADER_ONLY. That is, when you have foo depending on bar depending on baz, the link=static;define=BOOST_BAR_HEADER_ONLY property set is propagated from foo to bar to baz and everything works more or less as expected.
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only.
As we already discussed, sl/dl/hl have the problem that when a non-header-only library links to a header-only one which in turn links to a non-header-only one, the sl/dl of the first one should propagate to the third, which is problematic if the second has to be -hl.
As we also previously discussed, the easy way out of that is to enforce all header, all static or all shared. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
As we already discussed, sl/dl/hl have the problem that when a non-header-only library links to a header-only one which in turn links to a non-header-only one, the sl/dl of the first one should propagate to the third, which is problematic if the second has to be -hl.
As we also previously discussed, the easy way out of that is to enforce all header, all static or all shared.
But this is not possible in general as not all libraries support header-only. The preference for header-only, if supported, is orthogonal to the preference for static or shared. In sl/dl terms, it's not sl/dl/hl, it's sl/dl/slh/dlh, so that when you propagate downstream through a header-only library, the s/d isn't lost. In Boost.Build terms, these would be two separate features, link=static|shared and prefer-header-only=on. Libraries that don't have a header-only mode would just ignore the latter.
As we also previously discussed, the easy way out of that is to enforce all header, all static or all shared.
But this is not possible in general as not all libraries support header-only.
The preference for header-only, if supported, is orthogonal to the preference for static or shared. In sl/dl terms, it's not sl/dl/hl, it's sl/dl/slh/dlh, so that when you propagate downstream through a header-only library, the s/d isn't lost.
I think you're overcomplicating things. If a header only library has a dependency on a non-header only library capable of either static or shared usage, then the header only library simply advertises itself as having static or shared usage only. Not header only. In other words, header only targets means "nothing to link if you use this". Does this make sense now? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
I think you're overcomplicating things.
If a header only library has a dependency on a non-header only library capable of either static or shared usage, then the header only library simply advertises itself as having static or shared usage only. Not header only.
In other words, header only targets means "nothing to link if you use this". Does this make sense now?
The implication is that when a library changes from header-only to static/shared, all dependent libraries need to change themselves to static/shared too.
On 25/07/2017 23:01, Peter Dimov via Boost wrote:
Niall Douglas wrote:
I think you're overcomplicating things.
If a header only library has a dependency on a non-header only library capable of either static or shared usage, then the header only library simply advertises itself as having static or shared usage only. Not header only.
In other words, header only targets means "nothing to link if you use this". Does this make sense now?
The implication is that when a library changes from header-only to static/shared, all dependent libraries need to change themselves to static/shared too.
I'm not sure if this is a question or a statement. But in either case, yes it does. If the final library being consumed is static, all dependencies are static or header only. If the final library being consumed is shared, all dependencies are shared or header only. 95% of end users are probably okay with this default. Unusual needs like people who want static libraries of shared-ready code suitable for a final assembly into some monolithic shared library are likely niche users we need not consider deeply. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
The implication is that when a library changes from header-only to static/shared, all dependent libraries need to change themselves to static/shared too.
I'm not sure if this is a question or a statement. But in either case, yes it does.
My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything. And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.
On Wed, Jul 26, 2017 at 12:16 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Niall Douglas wrote:
The implication is that when a library changes from header-only to > static/shared, all dependent libraries need to change themselves to > static/shared too.
I'm not sure if this is a question or a statement. But in either case, yes it does.
My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything.
And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.
Isn't this automatic in Niall's scheme too? I don't know but it should be. -- Olaf
On 25/07/2017 23:16, Peter Dimov via Boost wrote:
Niall Douglas wrote:
The implication is that when a library changes from header-only to > static/shared, all dependent libraries need to change themselves to > static/shared too.
I'm not sure if this is a question or a statement. But in either case, yes it does.
My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything.
And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.
This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling! The big reason I keep advocating in favour of specific cmake targets for header-only libraries is because it solves auto-linking for all platforms without using linker magic. I think that a nice win for end users. It also could be extended easily to transparently use C++ Modules in the future, another nice win for end users. Can you suggest where, in the case of Boost, it would be important to support dependent libraries changing their header only usability? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 7/26/2017 4:22 PM, Niall Douglas via Boost wrote:
On 25/07/2017 23:16, Peter Dimov via Boost wrote:
Niall Douglas wrote:
The implication is that when a library changes from header-only to > static/shared, all dependent libraries need to change themselves to > static/shared too.
I'm not sure if this is a question or a statement. But in either case, yes it does.
My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything.
And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.
This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!
I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only. Furthermore, and most obviously, a non-header only library may have a great portion of its code as header only and just a small portion of its code as being built into a static or shared library. So another header only library might depend on a non-header only library, but could depend on only the code in the non-header only library which is header-only, or conversely could depend on the code which is part of a static or shared build of the non-header only library. And those dependencies could change as the design of a header only library evolves. Given all these very real possibilities, none of which should be important in forcing an actual design of a header only library, I find it absurd to "stop compiling" simply because the design of a build system is too simplistic to deal with the variations.
The big reason I keep advocating in favour of specific cmake targets for header-only libraries is because it solves auto-linking for all platforms without using linker magic. I think that a nice win for end users. It also could be extended easily to transparently use C++ Modules in the future, another nice win for end users.
Can you suggest where, in the case of Boost, it would be important to support dependent libraries changing their header only usability?
Niall
This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!
I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only.
I think this the crux of the misunderstanding. cmake doesn't implement header only library support as you and Peter appear to understand it. It implements INTERFACE targets. These are, quite literally, targets wholly composed of nothing. They cannot contain sources. They can inject paths to search for headers, compile and link flags into things which consume them. That's it. So when I've been speaking of implementing header only library support into cmake, I really mean targets consisting solely of how to find interface files, and how the final binary ought to be compiled and linked to keep the header only library happy. No non-wholly-interface-file dependencies permitted, though you can inject linking to arbitrary system or other libraries. The target dependency graph is *pure*.
Furthermore, and most obviously, a non-header only library may have a great portion of its code as header only and just a small portion of its code as being built into a static or shared library. So another header only library might depend on a non-header only library, but could depend on only the code in the non-header only library which is header-only, or conversely could depend on the code which is part of a static or shared build of the non-header only library. And those dependencies could change as the design of a header only library evolves.
All of which is fine if you adhere to the rule that header-only libraries with static or shared components or dependencies do not claim to be header-only. They claim themselves to be static or shared, as appropriate. There are quite a few libraries in Boost which are pure header only and with no dependencies on anything but other header only code. It is to these I refer only.
Given all these very real possibilities, none of which should be important in forcing an actual design of a header only library, I find it absurd to "stop compiling" simply because the design of a build system is too simplistic to deal with the variations.
The whole point of a decent build system is to refuse to build when requirements and/or guarantees have been broken. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wed, 2017-07-26 at 23:29 +0100, Niall Douglas via Boost wrote:
This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!
I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only.
I think this the crux of the misunderstanding.
cmake doesn't implement header only library support as you and Peter appear to understand it. It implements INTERFACE targets. These are, quite literally, targets wholly composed of nothing. They cannot contain sources. They can inject paths to search for headers, compile and link flags into things which consume them. That's it.
So when I've been speaking of implementing header only library support into cmake, I really mean targets consisting solely of how to find interface files, and how the final binary ought to be compiled and linked to keep the header only library happy. No non-wholly-interface-file dependencies permitted, though you can inject linking to arbitrary system or other libraries. The target dependency graph is *pure*.
The point in "modern cmake 3" if you will, is that I write: find_package(boost_foo) target_link_libraries(myLib boost::foo) And this will work whether boost_foo is header-only or compiled static or shared. Not only that, but if boost_foo or one of its dependents change from being header-only to being compiled(or vice versa), build scripts to boost_foo or any downstream libraries do not need to change. This is the usefulness of exporting usage requirements with build systems, and why it is important in cmake 3. What you are proposing does not provide this usefulness and is a major step backwards.
The point in "modern cmake 3" if you will, is that I write:
find_package(boost_foo) target_link_libraries(myLib boost::foo)
And this will work whether boost_foo is header-only or compiled static or shared. Not only that, but if boost_foo or one of its dependents change from being header-only to being compiled(or vice versa), build scripts to boost_foo or any downstream libraries do not need to change.
This is the usefulness of exporting usage requirements with build systems, and why it is important in cmake 3. What you are proposing does not provide this usefulness and is a major step backwards.
Where are you getting the notion that end users want to not care whether their dependencies are in header only, or static, or shared form? They're the ones suffering the build times. Of course they take strong opinions on it, they'll choose exactly one and contract into it permanently. They do not want you the library dev messing with that. That's why your proposed cmake 2-ish "directory per build config" system makes zero sense to me. Nobody in end user space wants to be mucking around on the command line with twenty lines of -Dvariable=setting and dealing with binaries being named weird things the library dev chose, in weird paths the library dev chose. They want to bring in the cmake for the library they're adding, and specifying *exactly* what presentation of that added dependency they are *contracting* into at the point of import, not separately on a command line with some voodoo magic list -D variable settings. *That's* cmake 3. It's reusable, it's a generic driver for external third party unknown cmake. Your proposal is exactly opposite that: you the library dev enforces what you think the end user wants by serving them a rigid menu of what you think is right for them. Regressive. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Thursday, July 27, 2017 2:06:49 AM CDT Niall Douglas via Boost wrote:
Where are you getting the notion that end users want to not care whether their dependencies are in header only, or static, or shared form?
I'm a user and generally: I don't care and certainly don't want to futz around with updating my code's build logic just because a library chose to change from static-only to header-only. -Steve
On 7/26/2017 6:29 PM, Niall Douglas via Boost wrote:
This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!
I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only.
I think this the crux of the misunderstanding.
cmake doesn't implement header only library support as you and Peter appear to understand it. It implements INTERFACE targets. These are, quite literally, targets wholly composed of nothing. They cannot contain sources. They can inject paths to search for headers, compile and link flags into things which consume them. That's it.
So when I've been speaking of implementing header only library support into cmake, I really mean targets consisting solely of how to find interface files, and how the final binary ought to be compiled and linked to keep the header only library happy. No non-wholly-interface-file dependencies permitted, though you can inject linking to arbitrary system or other libraries. The target dependency graph is *pure*.
Furthermore, and most obviously, a non-header only library may have a great portion of its code as header only and just a small portion of its code as being built into a static or shared library. So another header only library might depend on a non-header only library, but could depend on only the code in the non-header only library which is header-only, or conversely could depend on the code which is part of a static or shared build of the non-header only library. And those dependencies could change as the design of a header only library evolves.
All of which is fine if you adhere to the rule that header-only libraries with static or shared components or dependencies do not claim to be header-only. They claim themselves to be static or shared, as appropriate.
I assume you are talking about header only libraries with static/shared dependencies in CMake terms. Clearly in pure C++ terms a header only library which has static/shared library dependencies is still a header only library, which means that it itself does not have to be built even if its static/shared library dependency has to be built for the header only library to work properly. Since I do not know how CMake works and you do, I will defer to your assertion that a header only library with static/shared dependency should be treated as a STATIC or SHARED library and that CMake will work properly and know that the header only library itself has no build but that the STATIC or SHARED library dependency has to be built in order for the header only library to be "built" properly. That still sounds really odd to me but if it pragmatically works in CMake, that is what is important.
There are quite a few libraries in Boost which are pure header only and with no dependencies on anything but other header only code. It is to these I refer only.
Given all these very real possibilities, none of which should be important in forcing an actual design of a header only library, I find it absurd to "stop compiling" simply because the design of a build system is too simplistic to deal with the variations.
The whole point of a decent build system is to refuse to build when requirements and/or guarantees have been broken.
Niall
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.
This is provably untrue. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 24/07/17 21:07, Niall Douglas via Boost wrote:
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.
This is provably untrue.
It's entirely correct if you read what he was saying carefully. If you use a single target name "lib", this will be a shared library or a static library depending upon the build configuration (the BUILD_SHARED_LIBS option), or a header-only library. Supporting shared and static simultaneously isn't possible *with a single target name*. You would have to have e.g. "lib" and "lib-static". And on of the libraries e.g. the static library would need a mangled name since on Windows both the import library and the static library have a .lib extension and would clash with each other. Doing that is possible, but bad practice. The target names are mangled and not as usable downstream; downstream use has to commit to specific variants, and it's a lot less flexible. Choosing shared or static at configure time is the way cmake is designed to work, and it's the better choice here. (I have gone with the lib+list-static approach in the past and regretted it later.) Using normal fixed target names does not preclude mangling the binary name, which can be set independently as a target property. Roger
On 24/07/2017 21:27, Roger Leigh via Boost wrote:
On 24/07/17 21:07, Niall Douglas via Boost wrote:
Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.
This is provably untrue.
It's entirely correct if you read what he was saying carefully.
If and only if you start from the cmake 2 design pattern of a build directory per configuration. Which may be wise to choose for a long list of *other* reasons given the wider picture, but the reason that it is "natural", "correct", "modern" or any of the other things Paul is claiming is provably untrue. It for sure is not cmake 3 anyway. cmake 3's target based enhancements are unnecessary extra work and complication if you can hard assume a build directory per configuration. Just go ahead and set things based on directory as you did in cmake 2 e.g. add_definitions(). Make life easier on yourself. Skip all that cmake 3 target nonsense. And then ask yourself why bother with cmake 3 altogether if you're not using it? cmake 2.8.12 was perfectly fine. Let's use that, and lots of custom macros. Plenty of large scale cmake build systems work perfectly well with cmake 2.8.
If you use a single target name "lib", this will be a shared library or a static library depending upon the build configuration (the BUILD_SHARED_LIBS option), or a header-only library.
Supporting shared and static simultaneously isn't possible *with a single target name*. You would have to have e.g. "lib" and "lib-static". And on of the libraries e.g. the static library would need a mangled name since on Windows both the import library and the static library have a .lib extension and would clash with each other. Doing that is possible, but bad practice. The target names are mangled and not as usable downstream; downstream use has to commit to specific variants, and it's a lot less flexible. Choosing shared or static at configure time is the way cmake is designed to work, and it's the better choice here. (I have gone with the lib+list-static approach in the past and regretted it later.)
It is how cmake *was* designed to work in the 2000s. That was later discovered to be suboptimal. cmake 3's improvements enable very significant cmake scripting composability and reusability via a mostly or purely declarative target based specification, including reuse by unknown third party cmake. But I get the feeling that nobody here is listening. You're all set in your cmake ways and that's that. Before the SC made this decision, myself and Peter did up a reasonable prototype use case example for Boost cmake, I obviously think mine is better, but I still find his acceptable as his design was sound. It used an impure declarative design. It was okay. It was cmake 3 at least. If Boost proceeds down a path of build directory per config, I will fight it as hard as I can because I believe it to be seriously suboptimal. But in the end, it comes down to whomever is willing to do the work, and I am definitely not after my experience contributing to the git migration. If those willing to do the work are incapable of understanding cmake 3 design patterns, then Boost will have to adopt a cmake 2 design instead. So long as they don't dress it up as being "modern cmake", I'm fine with that. As I said earlier right at the top of this email, it may well be judged that whatever cmake a critical mass in the community can wrap their heads around is considered better than what is optimal or modern. And cmake 2.8 design patterns would have a critical mass far more than modern cmake, not least in terms of documentation and tutorials. So for all those *other reasons*, maybe a clean cmake 2.8 design is best after all. Just stop calling it anything other than cmake 2, because it's not. And don't pin the cmake version required to anything later than cmake 2.8.12, because you don't need to. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Roger Leigh wrote:
Similarly, the pkg-config one. I'm genuinely interested in how pkg-config support, if we have it, is supposed to handle multiple build variants having been installed.
I've already solved that for the cmake -config files, but I'm not sure I see a way for pkg-config to support it.
It's been a while since I looked at this, but my understanding is that it can't by design. You have one variant installed, with a matching set of pkg-config files which point to those libraries.
I implemented something along those lines. git clone the "feature/pkgconfig" branch of boostorg/boost, and then at the root (after having built b2) issue b2 tools/pkgconfig//stage This will stage the .pc files into stage/lib/pkgconfig. b2 tools/pkgconfig//install should also work and put them into $(prefix)/lib/pkgconfig. This is not a 100% working solution because of some irregular cases such as math, exception, test, stacktrace, and it doesn't contain the external dependencies such as -lrt ot -lbzip2 as I can't retrieve them automatically. But it could be useful nevertheless. Note that I'm generating .pc files for the header-only libraries as well, otherwise there's no way to track static -> header-only -> static dependencies properly.
On 22/07/17 20:00, Peter Dimov via Boost wrote:
Roger Leigh wrote:
Similarly, the pkg-config one. I'm genuinely interested in how > pkg-config support, if we have it, is supposed to handle multiple build > variants having been installed.
I've already solved that for the cmake -config files, but I'm not sure I > see a way for pkg-config to support it.
It's been a while since I looked at this, but my understanding is that it can't by design. You have one variant installed, with a matching set of pkg-config files which point to those libraries.
I implemented something along those lines. git clone the "feature/pkgconfig" branch of boostorg/boost, and then at the root (after having built b2) issue
b2 tools/pkgconfig//stage
This will stage the .pc files into stage/lib/pkgconfig.
b2 tools/pkgconfig//install
should also work and put them into $(prefix)/lib/pkgconfig.
This is not a 100% working solution because of some irregular cases such as math, exception, test, stacktrace, and it doesn't contain the external dependencies such as -lrt ot -lbzip2 as I can't retrieve them automatically. But it could be useful nevertheless.
Note that I'm generating .pc files for the header-only libraries as well, otherwise there's no way to track static -> header-only -> static dependencies properly.
That makes sense. I've given it a build and taken a look at the .pc files. Overall it looks very promising. I'll have to do a more rigourous check of the depedencies when I have some more free time. I'm unsure of the use of Requires.private for all dependencies, e.g. for filesystem: Cflags: -I${includedir} Libs: -L${libdir} -lboost_filesystem Requires.private: boost_assert = 1.65.0, boost_config = 1.65.0, boost_core = 1.65.0, boost_detail = 1.65.0, boost_functional = 1.65.0, boost_io = 1.65.0, boost_iterator = 1.65.0, boost_range = 1.65.0, boost_smart_ptr = 1.65.0, boost_static_assert = 1.65.0, boost_system = 1.65.0, boost_type_traits = 1.65.0 The boost_system dependency, for example, is required when linking to filesystem dynamically on Linux and BSD because the filesystem headers include the system headers, which forces system it to be explicitly linked even if you don't use it directly. The non-library components could certainly be private, but does it hurt to have them public? Are there some extra subtleties here? Other than that, the only minor cosmetic issue I saw was the duplication of the version in the description. Thanks, Roger
Roger Leigh wrote:
The boost_system dependency, for example, is required when linking to filesystem dynamically on Linux and BSD because the filesystem headers include the system headers, which forces system it to be explicitly linked even if you don't use it directly.
Yes, you're right, these dependencies should be public. (And the private ones weren't being added at all.) Fixed. Now that it's fixed, C:\Projects\boost-git>pkg-config --libs --static boost_log Æ A: out of memory This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. but, well. :-)
On 07/23/17 01:09, Peter Dimov via Boost wrote:
Roger Leigh wrote:
The boost_system dependency, for example, is required when linking to filesystem dynamically on Linux and BSD because the filesystem headers include the system headers, which forces system it to be explicitly linked even if you don't use it directly.
Yes, you're right, these dependencies should be public. (And the private ones weren't being added at all.) Fixed.
Now that it's fixed,
C:\Projects\boost-git>pkg-config --libs --static boost_log Æ A: out of memory This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.
but, well. :-)
It did succeed for me, but it took about 4.5GB and about 10 seconds to complete. :) BTW, there are two libraries in Boost.Log: libboost_log.so and libboost_log_setup.so (the latter is not mentioned in .pc). They have different dependencies, so if there were two separate .pc files, the list of dependencies could be shorter. But I suspect extracting that information from Boost.Build won't be easy.
Andrey Semashev wrote:
It did succeed for me, but it took about 4.5GB and about 10 seconds to complete. :)
Works then. :-) pkg-config seems polynomial of second (if not third) degree.
BTW, there are two libraries in Boost.Log: libboost_log.so and libboost_log_setup.so (the latter is not mentioned in .pc).
Yeah, I know about log_setup. It's one of the irregular cases. The problem is that, even if I special-case the additional library name, when someone includes a Log header, I can't tell to which of these two this should create a dependency. In a regular world, libs/foo should always build libboost_foo and nothing else and we would be done. On a related note, an interesting property of these .pc files is that, as currently generated, they are independent of the actual library build (depending on which would mean that the generation could only be done at `b2 install` time, that is, on the user machine.) As it stands though, these we can generate beforehand and include in the release (in f.ex. $BOOST_ROOT/pkgconfig) - but this necessarily implies that I can't include build time information such as actual file names.
On 07/23/17 03:14, Peter Dimov via Boost wrote:
On a related note, an interesting property of these .pc files is that, as currently generated, they are independent of the actual library build (depending on which would mean that the generation could only be done at `b2 install` time, that is, on the user machine.) As it stands though, these we can generate beforehand and include in the release (in f.ex. $BOOST_ROOT/pkgconfig) - but this necessarily implies that I can't include build time information such as actual file names.
But the -l switches should include name tags like -mt or -gd, if present, which are specific to the build config. (I didn't test that with the current implementation as no tags are produced by default on my Linux machine.) PS: As a totally wild idea, would it be possible to generate .pc files as an artefact of dynamically generated Boost.Build targets, each depending on a lib target in the library submodules? That would provide not only the target dependencies but also usage requirements.
Andrey Semashev wrote:
PS: As a totally wild idea, would it be possible to generate .pc files as an artefact of dynamically generated Boost.Build targets, each depending on a lib target in the library submodules? That would provide not only the target dependencies but also usage requirements.
It might be possible, esp. if all libraries are changed to use boost-lib instead of just lib (which sounds like a good idea in any case). I'm not sure I can do it though.
On Sat, Jul 22, 2017 at 1:18 PM, Roger Leigh via Boost <boost@lists.boost.org> wrote:
On 22/07/17 11:47, Peter Dimov via Boost wrote: This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.
What about multiple compiler versions, dynamic vs static library and dynamic vs static runtime? Until vcpkg this has been a disaster for me (on Windows). Having to collect outputs from multiple build trees and then hoping you're linking to the right one.. -- Olaf
On 07/22/17 13:47, Peter Dimov via Boost wrote:
Similarly, the pkg-config one. I'm genuinely interested in how pkg-config support, if we have it, is supposed to handle multiple build variants having been installed.
As a suggestion, we could generate differently named .pc files, similar to how we mangle binary names. When Boost is packaged though, it is typically compiled in just one configuration, so a single set of binaries is packaged and then installed in the end user system. In this scenario there is no need for name mangling, neither for binaries nor for .pc files.
Andrey Semashev wrote:
When Boost is packaged though, it is typically compiled in just one configuration, so a single set of binaries is packaged and then installed in the end user system.
Everyone seems to do it differently. Fedora: /usr/lib/libboost_filesystem.so.1.63.0 CentOS 7: /usr/lib64/libboost_filesystem-mt.so.1.53.0 /usr/lib64/libboost_filesystem.so.1.53.0 Ubuntu Trusty: /usr/lib/x86_64-linux-gnu/libboost_filesystem.a /usr/lib/x86_64-linux-gnu/libboost_filesystem.so That's not our problem though, we don't have control over that. What we'd need to do is generate .pc files on `b2 install`, and the number of files this would produce is not known ahead of time, it depends on the options the user gives.
On 07/22/17 15:06, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
When Boost is packaged though, it is typically compiled in just one configuration, so a single set of binaries is packaged and then installed in the end user system.
Everyone seems to do it differently.
Fedora:
/usr/lib/libboost_filesystem.so.1.63.0
CentOS 7:
/usr/lib64/libboost_filesystem-mt.so.1.53.0 /usr/lib64/libboost_filesystem.so.1.53.0
Those are probably the runtime packages. -devel packages should provide libboost_filesystem.so, which is a symlink to the full name with the version. pkg-config files are also installed with the -devel packages and contain flags that refer to the short names (i.e. libboost_filesystem.so). The -mt variant is uncommon though. I think, it is usually the default one and the single-threaded variant is not provided. Anyway, the -devel package could provide two .pc files - one per library variant.
Ubuntu Trusty:
/usr/lib/x86_64-linux-gnu/libboost_filesystem.a /usr/lib/x86_64-linux-gnu/libboost_filesystem.so
Right, that's what the -dev package provides. It depends on the runtime packages, which provides libboost_filesystem.so.<boost_version>.
That's not our problem though, we don't have control over that. What we'd need to do is generate .pc files on `b2 install`, and the number of files this would produce is not known ahead of time, it depends on the options the user gives.
Sure. I'm just saying that for .pc files we could follow te same route as we do with binaries now.
On Fri, Jul 21, 2017 at 4:25 PM, Roger Leigh via Boost <boost@lists.boost.org> wrote:
Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L...
Ouch. Wouldn't be even better of non-Windows toolsets supported auto-linking such that this wasn't necessary at all?
On 07/24/17 15:29, Olaf van der Spek via Boost wrote:
On Fri, Jul 21, 2017 at 4:25 PM, Roger Leigh via Boost <boost@lists.boost.org> wrote:
Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L...
Ouch. Wouldn't be even better of non-Windows toolsets supported auto-linking such that this wasn't necessary at all?
Auto-linking won't be easy because the order of linking matters.
On Mon, Jul 24, 2017 at 2:36 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
On 07/24/17 15:29, Olaf van der Spek via Boost wrote:
On Fri, Jul 21, 2017 at 4:25 PM, Roger Leigh via Boost <boost@lists.boost.org> wrote:
Could I also point to this block in
https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L...
Ouch. Wouldn't be even better of non-Windows toolsets supported auto-linking such that this wasn't necessary at all?
Auto-linking won't be easy because the order of linking matters.
Surely that's not an unsolvable problem. -- Olaf
On Tue, Jul 18, 2017 at 8:12 AM, Jon Kalb via Boost <boost@lists.boost.org> wrote:
The libraries produced by the Boost community have had a greater impact
on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. [snip] I have great respect for the Boost.Build project and its developers. Boost has received incredible mileage from this powerful tool. Perhaps it is only a matter of fate that Boost.Build has not received the same level of adoption as CMake. However, as the author of a Boost library (pending merge), I find the Boost.Build requirement to be burdensome, even for a header-only library. I spent many afternoons studying and using Boost.Build, but I still do not have a solid grasp of it. My experience learning and using CMake was significantly less frustrating. As the author and maintainer of an internal distro project that builds and packages 30+ open source projects, I find the build process for Boost to be cumbersome and peculiar. I strongly support the effort to steer Boost development and usage toward CMake. Ultimately, I believe this is a healthy move for our community. Additionally, I think the creation of a dedicated mailing list would be useful for those interested in contributing to this effort. This won't happen without focused collaboration. Barrett Adair
Am 18.07.2017 um 15:12 schrieb Jon Kalb via Boost:
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done.
The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem.
Preface: I'm on team boost.build. We had long discussions about the whole CMake vs boost.build thing and I will not reiterate those. I do think that boost.build is superior, but I might be wrong about that. I am however quite certain that the style of just announcing that this will happen is low. First of all, the discussion were not a stalemate, but rather open. Last year, there was an effort put in to explore the possibilities of boost.build v3; in the same way it would just be work to setup a cmake build for boost. As a matter of fact Paul Fultz II is working on that (https://github.com/pfultz2/boost-cmake) So this discussion was far from over and the proof that CMake would be superiour is lacking. So announcing the intention now by the steering comittee (instead of announcing the intention to build an example with Cmake) is premature; we have not only years of experience with boost.build but also the people who developed it. Well had, anyway. So prematurely declaring that boost will be going CMake without any technical proof is just bad. And given the amount of CMake proponents we have on this list: why isn't there a full boost CMake script yet? Why was there more effort put into maintaining boost.build than CMake? Seems to me, that the work put in should be of more importance, than the preferences stated on the mailing lists. Secondly there has never been a discussion whether another build system (or a fork thereof) might be better that CMake and boost.build (e.g. blaze, qbs, meson, scons). So how can the intention be to use CMake? Thirdly, the "it's like moving to git" is just an awful comparison. Boost.build was specifically build for boost and the superiority of git was way more clear than for CMake. For one: git can handle svn repositories. If CMake can build Jam-Files I'll be the first one to support it. Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost. Considering that your job is to do what's best for boost, you might want to reevaluate the way you operate. Losing Rene is surely not what is best for boost. The right way to do it, would've have been to setup a task force to evaluate the use of CMake. Announcing like that makes me wonder how profound the reasons for your decision actually are.
On 19/07/2017 18:08, Klemens Morgenstern via Boost wrote:
Am 18.07.2017 um 15:12 schrieb Jon Kalb via Boost:
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done.
The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem.
Preface: I'm on team boost.build.
We had long discussions about the whole CMake vs boost.build thing and I will not reiterate those. I do think that boost.build is superior, but I might be wrong about that.
My knowledge of Boot Build is quite limited, but that of CMake is quite extensive and I believe that CMake is indeed a superior tool when correctly used. Unfortunately, there are lots of bad examples out there as well people keeping on using ancient versions of it that are quite limited, in a similar way as when you compare C++98 to C++17.
I am however quite certain that the style of just announcing that this will happen is low. First of all, the discussion were not a stalemate, but rather open. Last year, there was an effort put in to explore the possibilities of boost.build v3; in the same way it would just be work to setup a cmake build for boost. As a matter of fact Paul Fultz II is working on that (https://github.com/pfultz2/boost-cmake) So this discussion was far from over and the proof that CMake would be superiour is lacking. So announcing the intention now by the steering comittee (instead of announcing the intention to build an example with Cmake) is premature; we have not only years of experience with boost.build but also the people who developed it. Well had, anyway. So prematurely declaring that boost will be going CMake without any technical proof is just bad. And given the amount of CMake proponents we have on this list: why isn't there a full boost CMake script yet? Why was there more effort put into maintaining boost.build than CMake? Seems to me, that the work put in should be of more importance, than the preferences stated on the mailing lists.
There are several examples of CMake built Boost in the wild already and even some using Bazel or Buck. I've made one of them and it's used in millions of user installs and works quite well so far! It's been open sourced here by the way: https://github.com/Orphis/boost-cmake . It supports building the library and integration in any project using "add_subdirectory()" and will even build and run quite a lot of tests in the standalone version to ensure libraries are built correctly. The target is users or the library, and they're happy with it since they don't have to deal with b2 and tons of prebuilt variants for their cross platform application. I started talking after the announcement to Paul Fultz II and others about contributing as well to target both users and Boost developers. I'll admit that my project doesn't build Boost Python as no one asked for it, but that would be trivial to add.
Secondly there has never been a discussion whether another build system (or a fork thereof) might be better that CMake and boost.build (e.g. blaze, qbs, meson, scons). So how can the intention be to use CMake?
I believe CMake has integrations in quite a lot of major IDEs and a community much larger than any of the other tools. It's becoming standard and ubiquitous.
Thirdly, the "it's like moving to git" is just an awful comparison. Boost.build was specifically build for boost and the superiority of git was way more clear than for CMake. For one: git can handle svn repositories. If CMake can build Jam-Files I'll be the first one to support it.
Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost.
Considering that your job is to do what's best for boost, you might want to reevaluate the way you operate. Losing Rene is surely not what is best for boost. The right way to do it, would've have been to setup a task force to evaluate the use of CMake. Announcing like that makes me wonder how profound the reasons for your decision actually are.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I looked at your Cmake file for a library I maintain - the boost.build links only against boost.thread if std::thread is not available (feature checks). I'm missing this feature in all Cmake files presented in this thread (dev/user ML). It seams that Cmake will always link against boost.thread. Beside this, other aspects in the Jamfile are not ported to Cmake too. I'm wondering why.
On 19/07/2017 21:01, Oliver Kowalke via Boost wrote:
I looked at your Cmake file for a library I maintain - the boost.build links only against boost.thread if std::thread is not available (feature checks). I'm missing this feature in all Cmake files presented in this thread (dev/user ML). It seams that Cmake will always link against boost.thread.
Beside this, other aspects in the Jamfile are not ported to Cmake too. I'm wondering why.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
It's simple, it's not peer reviewed and the intent isn't always obvious from looking at the Jamfile sometimes, I just know it works for my users and solves their issues. This feature can certainly be done though! Which library is it? My goal is to make it work for users so they get access to Boost and this is an optimization somehow. I would consider the linker not to use the thread library if it's not required and thus a non problem. Not all of the Jamfile has been ported to CMake too, only enough to make it work. My users don't need the non-threaded version of Boost for example and I didn't spent time on it, but it could be done. In the future, any proposal should implement all the variants (progressively, as needed) so I don't think this is representative, just saying it can be done. /Florent
As mentioned before - it is not only your cmake port, all presented boost-cmake files have ported only fraction of the required functionality. For instance feature tests used in Jamfile to test for presence/absence of some C++ features to control the build. If it's so easy to do it with Cmake I'm wondering why it wasn't done. I've the impression that only the easy parts of Jamfile have been ported. The difficult parts are left ... As Klemens already mentioned, I'm missing a discussion about the requirements of the boost build system and a comparison of pros/cons of other build systems on the ML.
On 7/19/2017 4:46 PM, Oliver Kowalke via Boost wrote:
As mentioned before - it is not only your cmake port, all presented boost-cmake files have ported only fraction of the required functionality. For instance feature tests used in Jamfile to test for presence/absence of some C++ features to control the build. If it's so easy to do it with Cmake I'm wondering why it wasn't done. I've the impression that only the easy parts of Jamfile have been ported. The difficult parts are left ...
Boost Build has the ability to run a 'program' and change the logic of what is to be built, or how something is to be built, based on the return value of that program. I do not know CMake well enough but I am assuming that CMake also has such a feature, else it would really be deficient IMO. That is essentially what Boost Config offers and Boost Predef offers and my briefly discussed Cxxd library also offered, through the facility in Boost Build which allows this. Porting Boost Config and Boost Predef to use CMake would have to port this ability also in an easy to use way, since other libraries also depend on the Boost Config and Boost Predef facilities when they use Boost Build for their purposes.
As Klemens already mentioned, I'm missing a discussion about the requirements of the boost build system and a comparison of pros/cons of other build systems on the ML.
On 19/07/2017 23:14, Edward Diener via Boost wrote:
On 7/19/2017 4:46 PM, Oliver Kowalke via Boost wrote:
As mentioned before - it is not only your cmake port, all presented boost-cmake files have ported only fraction of the required functionality. For instance feature tests used in Jamfile to test for presence/absence of some C++ features to control the build. If it's so easy to do it with Cmake I'm wondering why it wasn't done. I've the impression that only the easy parts of Jamfile have been ported. The difficult parts are left ...
Boost Build has the ability to run a 'program' and change the logic of what is to be built, or how something is to be built, based on the return value of that program. I do not know CMake well enough but I am assuming that CMake also has such a feature, else it would really be deficient IMO. That is essentially what Boost Config offers and Boost Predef offers and my briefly discussed Cxxd library also offered, through the facility in Boost Build which allows this. Porting Boost Config and Boost Predef to use CMake would have to port this ability also in an easy to use way, since other libraries also depend on the Boost Config and Boost Predef facilities when they use Boost Build for their purposes.
This is indeed possible: https://cmake.org/cmake/help/v3.8/command/try_compile.html#command:try_compi... Usually, you don't need to run them since you might be cross compiling for a weird platform and can't run programs for it, so it's better if the check can be done at compile time. If you just want to check a header exists or just symbols, there are some other dedicated functions too that are a bit more convenient.
As Klemens already mentioned, I'm missing a discussion about the requirements of the boost build system and a comparison of pros/cons of other build systems on the ML.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, 2017-07-19 at 17:14 -0400, Edward Diener via Boost wrote:
On 7/19/2017 4:46 PM, Oliver Kowalke via Boost wrote:
As mentioned before - it is not only your cmake port, all presented boost-cmake files have ported only fraction of the required functionality. For instance feature tests used in Jamfile to test for presence/absence of some C++ features to control the build. If it's so easy to do it with Cmake I'm wondering why it wasn't done. I've the impression that only the easy parts of Jamfile have been ported. The difficult parts are left ...
Boost Build has the ability to run a 'program' and change the logic of what is to be built, or how something is to be built, based on the return value of that program. I do not know CMake well enough but I am assuming that CMake also has such a feature, else it would really be deficient IMO. That is essentially what Boost Config offers and Boost Predef offers and my briefly discussed Cxxd library also offered, through the facility in Boost Build which allows this. Porting Boost Config and Boost Predef to use CMake would have to port this ability also in an easy to use way, since other libraries also depend on the Boost Config and Boost Predef facilities when they use Boost Build for their purposes.
Yes, the idea is to provide a custom cmake function like `boost_config_feature_check` that will do the check for the user. This function would be provided when the user calls `find_package(boost_config)`. And would need to be generated in Boost.Config's package configuration. To do it exactly the same as bjam currently we would need to install the .ipp files as well, but alternatively we could feature check by checking if the define is available in boost config's headers, which has the advantage of being consistent during build and compilation.
As mentioned before - it is not only your cmake port, all presented boost-cmake files have ported only fraction of the required functionality. For instance feature tests used in Jamfile to test for presence/absence of some C++ features to control the build. Funny you mention that, I recently did some (porting) work on a library
On 19/07/2017 22:46, Oliver Kowalke via Boost wrote: that was planning to move to boost. The project uses CMake (because...well, documentation, support, real world compatibility, etc.. it's already been discussed). I needed to known if some feature was available so I started using a try_(compile|run)... and was asked to refrain from it as "you, know, at some point will have to use bjam, so we need to stick to basic stuff."
If it's so easy to do it with Cmake I'm wondering why it wasn't done. I've the impression that only the easy parts of Jamfile have been ported. The difficult parts are left ...
As Klemens already mentioned, I'm missing a discussion about the requirements of the boost build system and a comparison of pros/cons of other build systems on the ML.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'd like to weigh in as a consumer and occasional patcher of the Boost library. My company uses boost extensively for our cross-platform Windows and Mac OS X C++ application. We maintain two build systems, a Xcode project for Mac-specific components and a *huge* CMake tree that builds our dependencies, proprietary libraries, and tests. We use CMake because it is extremely flexible for different dependency strategies on our target platforms, because it integrates cleanly with our IDEs (My team members use both Xcode and CLion), and because it's relatively easy to maintain the CMakeLists for the majority of our modules. I must admit that I was initially resistant to propagating CMake through our projects but I came around after being part of a minor refactor that we did to modularize some of our code. This effort required writing new CMakeLists and splicing some existing ones into new library targets. It was just as easy to do by hand in the CMakeLists as I was used to doing in our Xcode projects (Xcode is my preferred IDE). I fully support the proposed long-term goal of switching to CMake as the Boost build system, both personally and as a representative of my professional development team. I understand that there is a great deal of sunk cost, history, and personal affinity with Boost.Build/B2. I can only offer inconsequential anecdotes related to attempting to integrate B2 builds the existing build system of a myriad of projects in different organizations. With that disclaimer, I want to say that I have been disappointed with the complexity of the B2 system and it has definitely turned me off as a development. As a library user, it's generally been simple enough to script a "dumb" build task in B2 and then hardcode some usage of the resultant binaries. However, that was completely unacceptable for the current project I lead. I realize that experienced and devoted developers of Boost have a totally different experience interacting with the build system, this is just my perspective. I'd like to offer whatever help I can muster with regard to adopting CMake in Boost. My team practically celebrated when we heard about this proposal. I've posted our semi-proprietary Boost CMakeLists on GitHub. Maybe they'll be useful for a porting effort. https://github.com/GroundControl-Solutions/boost-cmake <https://github.com/GroundControl-Solutions/boost-cmake> Regards, Jeremy Agostino CTO GroundControl Solutions, Inc. -- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 7/21/17 12:04 PM, JeremyAgost via Boost wrote:
I'd like to offer whatever help I can muster with regard to adopting CMake in Boost. My team practically celebrated when we heard about this proposal. I've posted our semi-proprietary Boost CMakeLists on GitHub. Maybe they'll be useful for a porting effort. https://github.com/GroundControl-Solutions/boost-cmake <https://github.com/GroundControl-Solutions/boost-cmake>
This very interesting and constructive. Having make the CMake files for the library I maintain, the serialization library I have some exposure to this so I have a couple of questions: a) My main interest has been to use CMake to generate Xcode IDE files. I find the settings for the Xcode IDE all over the place - same as for Visual Studio. I find them easier to set in CMakeLists.txt. b) I don't see where you've included the header files. I need these to work with the IDE. c) I see you've made provision for static and dynamic libraries. Good, I did something similar to the same. d) I don't see where CTest is being invoked to compile and run the tests. Again, specific examples are very helpful in following proposals. Robert Ramey
Regards, Jeremy Agostino CTO GroundControl Solutions, Inc.
-- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 19/07/2017 18:08, Klemens Morgenstern via Boost wrote:
Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost.
Maybe it's just me, but paying for Boost.Build effort to better document it, clean it a bit and adding the feature of automatically generate CMake (and maybe the infrastructure to build system projects) and packagin utilities for major distros would be relatively cheap and extremely useful to easy the use of Boost. Like regressions test infrastructure, it's a basic building block for Boost so it should get a different treatment from other libraries. Ion
Am 19.07.2017 um 18:38 schrieb Ion Gaztañaga via Boost:
On 19/07/2017 18:08, Klemens Morgenstern via Boost wrote:
Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost.
Maybe it's just me, but paying for Boost.Build effort to better document it, clean it a bit and adding the feature of automatically generate CMake (and maybe the infrastructure to build system projects) and packagin utilities for major distros would be relatively cheap and extremely useful to easy the use of Boost.
That is just you. I give you the one on the the documentation, though it would be a stretch to claim CMake is any better in that regard. "adding the feature of automatically generate CMake" is a huge task and completely pointless, if boost.build works. Much better would be to extend the FindBoost.cmake with a small descriptions of the steps to build boost if required.
Like regressions test infrastructure, it's a basic building block for Boost so it should get a different treatment from other libraries.
And it's actually a tool used by people outside of boost. GIven the announcement it just got killed off, which could be a first. I mean boost maintains old libraries like boost.iostreams. Since we're not deprecating tools, why not also throw out some libraries?
Ion
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/19/2017 11:08 AM, Klemens Morgenstern via Boost wrote:
Am 18.07.2017 um 15:12 schrieb Jon Kalb via Boost:
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done.
The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem.
Preface: I'm on team boost.build.
We had long discussions about the whole CMake vs boost.build thing and I will not reiterate those. I do think that boost.build is superior, but I might be wrong about that.
I am however quite certain that the style of just announcing that this will happen is low. First of all, the discussion were not a stalemate, but rather open. Last year, there was an effort put in to explore the possibilities of boost.build v3; in the same way it would just be work to setup a cmake build for boost. As a matter of fact Paul Fultz II is working on that (https://github.com/pfultz2/boost-cmake) So this discussion was far from over and the proof that CMake would be superiour is lacking. So announcing the intention now by the steering comittee (instead of announcing the intention to build an example with Cmake) is premature; we have not only years of experience with boost.build but also the people who developed it. Well had, anyway. So prematurely declaring that boost will be going CMake without any technical proof is just bad. And given the amount of CMake proponents we have on this list: why isn't there a full boost CMake script yet? Why was there more effort put into maintaining boost.build than CMake? Seems to me, that the work put in should be of more importance, than the preferences stated on the mailing lists.
Secondly there has never been a discussion whether another build system (or a fork thereof) might be better that CMake and boost.build (e.g. blaze, qbs, meson, scons). So how can the intention be to use CMake?
Thirdly, the "it's like moving to git" is just an awful comparison. Boost.build was specifically build for boost and the superiority of git was way more clear than for CMake. For one: git can handle svn repositories. If CMake can build Jam-Files I'll be the first one to support it.
Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost.
Considering that your job is to do what's best for boost, you might want to reevaluate the way you operate. Losing Rene is surely not what is best for boost. The right way to do it, would've have been to setup a task force to evaluate the use of CMake. Announcing like that makes me wonder how profound the reasons for your decision actually are.
I agree with all your points. Thank you very much. I have professional concerns on how the SC is operating. I am confident many others do too. Here is an executive summary: Boost library use is recently incorporated here at my employer. I have been successfully building every Boost release since 1.55 for both Intel and Visual Studio on Windows. The Cmake announcement method affects how and whether my employer will continue to use Boost libraries. Has the SC given any thought of how an extreme announcement, lacking technical factual consensus, affects every single user, developer, software engineer, software architect, principal software engineer, project manager, technical lead, software engineering manager, product managers, etc.? The Boost library list itself is proof that thorough design and architecture discussions occur on everything prior to inclusion. Then, if it is approved by the C++ Standards Committee, a library could become part of the official standard! The Cmake announcement is totally contrary to the established review process, as well as the page that summarizes all of the labor hours and source code lines that constitute Boost. For reference, see this URL by Rene Rivera: http://www.boost.org/development/index.html. Thank you for your time, Robert
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
For whatever its worth as a user for 12 years, and someone who would like to contribute more then a rare bugfix, I'm glad the SC stepped in. I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up. Its not like there haven't been concerns about boost.build for years. Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years. Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC. Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch. These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github. On Wed, Jul 26, 2017 at 1:33 PM, Robert via Boost <boost@lists.boost.org> wrote:
On 7/19/2017 11:08 AM, Klemens Morgenstern via Boost wrote:
Am 18.07.2017 um 15:12 schrieb Jon Kalb via Boost:
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers.
We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done.
The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem.
Preface: I'm on team boost.build.
We had long discussions about the whole CMake vs boost.build thing and I will not reiterate those. I do think that boost.build is superior, but I might be wrong about that.
I am however quite certain that the style of just announcing that this will happen is low. First of all, the discussion were not a stalemate, but rather open. Last year, there was an effort put in to explore the possibilities of boost.build v3; in the same way it would just be work to setup a cmake build for boost. As a matter of fact Paul Fultz II is working on that (https://github.com/pfultz2/boost-cmake) So this discussion was far from over and the proof that CMake would be superiour is lacking. So announcing the intention now by the steering comittee (instead of announcing the intention to build an example with Cmake) is premature; we have not only years of experience with boost.build but also the people who developed it. Well had, anyway. So prematurely declaring that boost will be going CMake without any technical proof is just bad. And given the amount of CMake proponents we have on this list: why isn't there a full boost CMake script yet? Why was there more effort put into maintaining boost.build than CMake? Seems to me, that the work put in should be of more importance, than the preferences stated on the mailing lists.
Secondly there has never been a discussion whether another build system (or a fork thereof) might be better that CMake and boost.build (e.g. blaze, qbs, meson, scons). So how can the intention be to use CMake?
Thirdly, the "it's like moving to git" is just an awful comparison. Boost.build was specifically build for boost and the superiority of git was way more clear than for CMake. For one: git can handle svn repositories. If CMake can build Jam-Files I'll be the first one to support it.
Fourthly I don't think the comittee does understand how much work this will be for the maintainers of certain libraries, such as boost.python. For header only libraries with trivial tests, I don't think it'll be much work, but I don't see the steering comittee or those crying for CMake doing the implementation for the more compilicated libraries. This decision will put constraints on many maintainers and some of them will see this as an artificial requirement. Now we can handle that if we get paid; but for projects we do for free, some of us will consider that too frustrating and jump ship. And since the first response was Rene, I think this could really hurt boost.
Considering that your job is to do what's best for boost, you might want to reevaluate the way you operate. Losing Rene is surely not what is best for boost. The right way to do it, would've have been to setup a task force to evaluate the use of CMake. Announcing like that makes me wonder how profound the reasons for your decision actually are.
I agree with all your points. Thank you very much. I have professional concerns on how the SC is operating. I am confident many others do too. Here is an executive summary:
Boost library use is recently incorporated here at my employer. I have been successfully building every Boost release since 1.55 for both Intel and Visual Studio on Windows. The Cmake announcement method affects how and whether my employer will continue to use Boost libraries. Has the SC given any thought of how an extreme announcement, lacking technical factual consensus, affects every single user, developer, software engineer, software architect, principal software engineer, project manager, technical lead, software engineering manager, product managers, etc.? The Boost library list itself is proof that thorough design and architecture discussions occur on everything prior to inclusion. Then, if it is approved by the C++ Standards Committee, a library could become part of the official standard! The Cmake announcement is totally contrary to the established review process, as well as the page that summarizes all of the labor hours and source code lines that constitute Boost. For reference, see this URL by Rene Rivera: http://www.boost.org/development/index.html.
Thank you for your time,
Robert
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Jul 27, 2017 at 6:01 AM, Gary Furnish via Boost <boost@lists.boost.org> wrote:
For whatever its worth as a user for 12 years, and someone who would like to contribute more then a rare bugfix, I'm glad the SC stepped in. I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up. Its not like there haven't been concerns about boost.build for years. Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years. Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC. Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch. These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github.
I think nobody disagrees the build system could and should be improved. -- Olaf
Right my point was that 1) Users haven't had a voice in the discussion for far too long 2) What needed to be improved has been known largely for 10 years and it never got done. Why would anyone think that the status quo would change for the better with more meetings? On Thu, Jul 27, 2017 at 3:32 AM, Olaf van der Spek via Boost <boost@lists.boost.org> wrote:
On Thu, Jul 27, 2017 at 6:01 AM, Gary Furnish via Boost <boost@lists.boost.org> wrote:
For whatever its worth as a user for 12 years, and someone who would like to contribute more then a rare bugfix, I'm glad the SC stepped in. I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up. Its not like there haven't been concerns about boost.build for years. Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years. Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC. Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch. These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github.
I think nobody disagrees the build system could and should be improved.
-- Olaf
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Since you are making a variety of accusations.. On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost < boost@lists.boost.org> wrote:
I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up.
Prove it.
Its not like there haven't been concerns about boost.build for years.
All build systems, heck all software, has "concerns".
Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years.
The documentation is bad compared to what other documentation?
Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC.
Prove that it wasn't a priority. Considering that the last Boost release was delayed precisely to support MSVC building.
Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch.
Again, prove it.
These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github.
Prove that the build system is the reason Boost is "dying a slow death"? For that matter prove that Boost is dying in the first place. Note.. Yes I will keep posting in these threads in response to false accusations to the decades of work some of us have put into Boost. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Since you are making a variety of accusations..
On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost < boost@lists.boost.org> wrote:
I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up.
Prove it. Sure. See the discussions where if you aren't doing things the boost-build way and are instead a config-per-directory way your basically considered a second class citizen in spite of that being the way the rest of the oss world works. The fact that it is still non-obvious how to do this without touching anything besides a build
On Thu, Jul 27, 2017 at 8:40 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote: directory is awful. This should be somewhere in big bold letters.
Its not like there haven't been concerns about boost.build for years.
All build systems, heck all software, has "concerns".
Yes but the issues that I'm talking about are things that have been an issue for years and never got fixed. See also silently dropping flags if you use a space and don't quote in bjam files (something also not obvious and yet important to pass compiler flags!). At least CMAKE/most sane build systems will put up errors somewhere along the lines.
Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years.
The documentation is bad compared to what other documentation?
The documentation is bad compared to say, CMAKE, which isn't great in the first place. Setting up an out of build directory has always been a pain with poorly documented flags needing to be invoked to share a common source directory (and its worth noting that I'm not sure its technically parallel safe in any reasonable way given the need to bootstrap and create header links and what not).
Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC.
Prove that it wasn't a priority. Considering that the last Boost release was delayed precisely to support MSVC building.
It was delayed to support the final release. CMAKE supported it from the first beta. Given that MSVC is specifically making an effort to implement features to be part of the standards process, this is basically a choice between using boost or being on MSVC's and C++ cutting edge. Support for MSVC has basically always been this bad as far as I remember. It should have never been necessary to delay a release to support a key platform when there were four betas.
Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch.
Again, prove it.
I've seen a number of emails here where people basically said "and then I had to learn this extra crazy language to get stuff into boost." I'm not sure why this is a contentious point. By definition you have to learn an entire new build system to get something into boost. Is there a simple "and this is what you need to do to build a new module in boost webpage?" No there isn't. There never has been.
These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github.
Prove that the build system is the reason Boost is "dying a slow death"? For that matter prove that Boost is dying in the first place.
How many of the latest proposals for C++ have actually been in boost? Ranges? Polymorphic allocators? I can not remember the last time I watched a CPPCON/etc video and someone was talking about bringing something from boost into the standard library besides filesystem (which is legacy) or asio (which technically is standalone).
Note.. Yes I will keep posting in these threads in response to false accusations to the decades of work some of us have put into Boost.
Standing here and shouting at users for for making "false accusations" when they have real, specific issues with boost is not a way to make boost look friendly or the place to contribute to.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, Jul 27, 2017 at 8:28 AM, Gary Furnish via Boost <boost@lists.boost.org> wrote:
How many of the latest proposals for C++ have actually been in boost? Ranges? Polymorphic allocators? I can not remember the last time I watched a CPPCON/etc video and someone was talking about bringing something from boost into the standard library besides filesystem (which is legacy) or asio (which technically is standalone).
That's only because it is possible for a proposal to be accepted having just a paper, and sometimes no implementation (sized delete anyone?) One individual, who currently has a proposal far along, said to the effect that they skipped submitting to Boost first because the formal review process was too demanding and time consuming, and they wanted to get their proposal in to C++20. I disagree with this practice. A TS should be backed by a library that is already in use, which appears in an actual released product whether it is Boost or a standalone library, that has a version number, quality control, tests, and existing users. That is the route that I have chosen for Beast, so that the library may age in the Boost cask. To summarize, fewer proposals are coming from Boost because the standards for proposals have not been raised to meet at least the level of excellence required of a Boost library. Thanks
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gary Furnish via Boost Sent: 27 July 2017 16:28 To: boost@lists.boost.org Cc: Gary Furnish Subject: Re: [boost] CMake Announcement from Boost Steering Committee
On Thu, Jul 27, 2017 at 8:40 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:
Since you are making a variety of accusations..
On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost < boost@lists.boost.org> wrote:
I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up.
Although there was obviously enthusiasm for a build tool by its authors and successful users, and they would not be human otherwise. There were, and still are, doubts about whether and how CMake could replicate it. And there was nobody offering who knew enough to advise and willing to act. Previous effort had stalled, perhaps because earlier CMake could not then replicate the effect of bjam jamfiles? It is only recently, (before the SC missive), that people are beginning to provide solutions and explanations, and some are even offering to actually put I the effort to make CMake work. I'm still very concerned at the work involved by all the many library authors to change; we have enough trouble with maintenance already :-( I strongly disapprove of the manner of the Steering Committee announcement, but it has certainly broken a logjam; of course, there will be downstream damage from the logs! I don't think that continuing this recriminating conversation about the past is going to be helpful. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 7/27/2017 11:28 AM, Gary Furnish via Boost wrote:
On Thu, Jul 27, 2017 at 8:40 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:
Since you are making a variety of accusations..
On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost < boost@lists.boost.org> wrote:
I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up.
Prove it. Sure. See the discussions where if you aren't doing things the boost-build way and are instead a config-per-directory way your basically considered a second class citizen in spite of that being the way the rest of the oss world works.
Please give a URL to these discussions you are citing. Granted that Boost Build creates output in a different structure than CMake does, where you get the rest of your complaint I do not know.
The fact that it is still non-obvious how to do this without touching anything besides a build directory is awful. This should be somewhere in big bold letters.
Its not like there haven't been concerns about boost.build for years.
All build systems, heck all software, has "concerns".
Yes but the issues that I'm talking about are things that have been an issue for years and never got fixed. See also silently dropping flags if you use a space and don't quote in bjam files (something also not obvious and yet important to pass compiler flags!). At least CMAKE/most sane build systems will put up errors somewhere along the lines.
Are these so-called issues documented anywhere in Boost Trac ? Have PRs been created for these issues ? Have these issues been discussed on the Boost mailing lists ? If so, please cite where.
Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years.
The documentation is bad compared to what other documentation?
The documentation is bad compared to say, CMAKE, which isn't great in the first place.
CMake docs are just a list of various subjects without any overviews of how to use anything. I do not call that better than Boost Build, and I do not thing that Boost Build documentation is great either.
Setting up an out of build directory has always been a pain with poorly documented flags needing to be invoked to share a common source directory (and its worth noting that I'm not sure its technically parallel safe in any reasonable way given the need to bootstrap and create header links and what not).
Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC.
Prove that it wasn't a priority. Considering that the last Boost release was delayed precisely to support MSVC building.
It was delayed to support the final release. CMAKE supported it from the first beta. Given that MSVC is specifically making an effort to implement features to be part of the standards process, this is basically a choice between using boost or being on MSVC's and C++ cutting edge. Support for MSVC has basically always been this bad as far as I remember. It should have never been necessary to delay a release to support a key platform when there were four betas.
Four betas that were in constant flux but you think that it is up to Boost to constantly follow VC++'s changes as they roll out a new release over an extended time period. Boost has constantly gone out of its way to accommodate Microsoft and VC++. Any breakage that occurs is because VC++ has always been behind gcc and clang as far as C++ standards compliance. Needless to say the VC++ preprocessor has never been C++ standards compliant and lack of such things like two-phase lookup has repeatedly broken C++ standards compliance in the sort of corner cases which advanced C++ code as evidenced by Boost libraries entails. You are way out of line on this item. If you had any real knowledge of Boost library code you would know that the vast majority of one-off fixes are for the VC++ compilers. That has certainly improved with the latest VC++ release(s), but to say that Boost does not and has not gone out of its way tro accommodate VC++ is just wrong.
Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch.
Again, prove it.
I've seen a number of emails here where people basically said "and then I had to learn this extra crazy language to get stuff into boost." I'm not sure why this is a contentious point. By definition you have to learn an entire new build system to get something into boost. Is there a simple "and this is what you need to do to build a new module in boost webpage?" No there isn't. There never has been.
I agree with this. For potential library developers there should have been a web page for setting up Boost Build to build, test, and possibly write docs for a Boost library. Either that or this "use cases" methodology for library developers should have been a prominent part of the Boost Build docs.
These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github.
Prove that the build system is the reason Boost is "dying a slow death"? For that matter prove that Boost is dying in the first place.
How many of the latest proposals for C++ have actually been in boost? Ranges? Polymorphic allocators? I can not remember the last time I watched a CPPCON/etc video and someone was talking about bringing something from boost into the standard library besides filesystem (which is legacy) or asio (which technically is standalone).
How many new libraries do you think that the C++ standards committee ever accepts into the C++ standard ? Very, very few out of all the potential libraries in Boost or otherwise that might come to their attention. The real test is whether C++ developers rely on any of the 130+ libraries under the Boost umbrella. I think quite a few still do.
Note.. Yes I will keep posting in these threads in response to false accusations to the decades of work some of us have put into Boost.
Standing here and shouting at users for for making "false accusations" when they have real, specific issues with boost is not a way to make boost look friendly or the place to contribute to.
No one is shouting. It is a give-and-take discussion. I for one am satisfied that if the Boost Steering Committee want to change to CMake that is fine and Boost needs to do so to accommodate C++ developers and end-users who are more used to CMake and its ways of doing things.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Thu, Jul 27, 2017 at 10:30 AM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 7/27/2017 11:28 AM, Gary Furnish via Boost wrote:
On Thu, Jul 27, 2017 at 8:40 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:
Since you are making a variety of accusations..
On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost < boost@lists.boost.org> wrote:
I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up.
Prove it.
Sure. See the discussions where if you aren't doing things the boost-build way and are instead a config-per-directory way your basically considered a second class citizen in spite of that being the way the rest of the oss world works.
Please give a URL to these discussions you are citing. Granted that Boost Build creates output in a different structure than CMake does, where you get the rest of your complaint I do not know.
I don't have a specific discussion so much as the feeling that in discussions leading up to the SC there was a very us against them mentality on the part of people who like boost.build. Its not a very welcoming place to comment as a user/minor bug fix contributor.
The fact that it is still non-obvious how to do this without touching anything besides a build directory is awful. This should be somewhere in big bold letters.
Its not like there haven't been concerns about boost.build for years.
All build systems, heck all software, has "concerns".
Yes but the issues that I'm talking about are things that have been an issue for years and never got fixed. See also silently dropping flags if you use a space and don't quote in bjam files (something also not obvious and yet important to pass compiler flags!). At least CMAKE/most sane build systems will put up errors somewhere along the lines.
Are these so-called issues documented anywhere in Boost Trac ? Have PRs been created for these issues ? Have these issues been discussed on the Boost mailing lists ? If so, please cite where.
I have no idea, but I know that they come up enough that build questions are pretty persistent on stack overflow compared to other c++ software in my opinion. Boost has by far the hardest to understand system as a user of anything I've dealt with, including setting up cross compiling gcc which is no picnic. I have seen the whitespace issue dismissed as intended behavior because of the way the lexer works in a thread at one point, but its an intended behavior that is very user unfriendly.
Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years.
The documentation is bad compared to what other documentation?
The documentation is bad compared to say, CMAKE, which isn't great in the first place.
CMake docs are just a list of various subjects without any overviews of how to use anything. I do not call that better than Boost Build, and I do not thing that Boost Build documentation is great either. Yes but plenty of people have written CMake tutorials. Boost.build not so much.
Setting up an out of build directory has always been a pain with poorly documented flags needing to be invoked to share a common source directory (and its worth noting that I'm not sure its technically parallel safe in any reasonable way given the need to bootstrap and create header links and what not).
Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC.
Prove that it wasn't a priority. Considering that the last Boost release was delayed precisely to support MSVC building.
It was delayed to support the final release. CMAKE supported it from the first beta. Given that MSVC is specifically making an effort to implement features to be part of the standards process, this is basically a choice between using boost or being on MSVC's and C++ cutting edge. Support for MSVC has basically always been this bad as far as I remember. It should have never been necessary to delay a release to support a key platform when there were four betas.
Four betas that were in constant flux but you think that it is up to Boost to constantly follow VC++'s changes as they roll out a new release over an extended time period. Boost has constantly gone out of its way to accommodate Microsoft and VC++. Any breakage that occurs is because VC++ has always been behind gcc and clang as far as C++ standards compliance. Needless to say the VC++ preprocessor has never been C++ standards compliant and lack of such things like two-phase lookup has repeatedly broken C++ standards compliance in the sort of corner cases which advanced C++ code as evidenced by Boost libraries entails. You are way out of line on this item. If you had any real knowledge of Boost library code you would know that the vast majority of one-off fixes are for the VC++ compilers. That has certainly improved with the latest VC++ release(s), but to say that Boost does not and has not gone out of its way tro accommodate VC++ is just wrong.
Honestly standards compliance errors are great, I can fix those locally. If I could persistently get to those I would be happy. What has always been a problem is when feature detection or compiler detection goes wrong, and everything blows up before I even get a chance to find real errors. This is a design flaw. If MSVC next version comes out, I should at least be able to try to build what worked last version.
Its not like everyone submitting to boost doesn't complain about having to learn a non-standard build system that isn't documented richly enough to write scripts from scratch.
Again, prove it.
I've seen a number of emails here where people basically said "and then I had to learn this extra crazy language to get stuff into boost." I'm not sure why this is a contentious point. By definition you have to learn an entire new build system to get something into boost. Is there a simple "and this is what you need to do to build a new module in boost webpage?" No there isn't. There never has been.
I agree with this. For potential library developers there should have been a web page for setting up Boost Build to build, test, and possibly write docs for a Boost library. Either that or this "use cases" methodology for library developers should have been a prominent part of the Boost Build docs.
These are not new problems. I am *really* glad that SC did something because in my mind it means boost won't die a slow death to just posting independent libs on github.
Prove that the build system is the reason Boost is "dying a slow death"? For that matter prove that Boost is dying in the first place.
How many of the latest proposals for C++ have actually been in boost? Ranges? Polymorphic allocators? I can not remember the last time I watched a CPPCON/etc video and someone was talking about bringing something from boost into the standard library besides filesystem (which is legacy) or asio (which technically is standalone).
How many new libraries do you think that the C++ standards committee ever accepts into the C++ standard ? Very, very few out of all the potential libraries in Boost or otherwise that might come to their attention. The real test is whether C++ developers rely on any of the 130+ libraries under the Boost umbrella. I think quite a few still do.
Maybe, but the more non-standardish things that have to be done the more you put on peoples plates... (I think its interesting GSL got done under non-boost header too given that boost seems to be the perfect place to have put/used that).
Note.. Yes I will keep posting in these threads in response to false accusations to the decades of work some of us have put into Boost.
Standing here and shouting at users for for making "false accusations" when they have real, specific issues with boost is not a way to make boost look friendly or the place to contribute to.
No one is shouting. It certainly feels like some people are not very friendly on the issue. I realize that's a feeling, but the mailing list is not exactly a friendly place sometimes for people who aren't in the core-dev crowd. It is a give-and-take discussion. I for one am satisfied that if the Boost Steering Committee want to change to CMake that is fine and Boost needs to do so to accommodate C++ developers and end-users who are more used to CMake and its ways of doing things.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 7/27/2017 2:42 PM, Gary Furnish via Boost wrote:
On Thu, Jul 27, 2017 at 10:30 AM, Edward Diener via Boost <boost@lists.boost.org> wrote:
On 7/27/2017 11:28 AM, Gary Furnish via Boost wrote:
On Thu, Jul 27, 2017 at 8:40 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:
Since you are making a variety of accusations..
On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost < boost@lists.boost.org> wrote:
I've observed from the outside that basically no one was ever going to touch boost.build because the people who like it (who happen to be single points of failure for the entire boost ecosystem) basically out-shouted everyone whenever a technical discussion came up.
Prove it.
Sure. See the discussions where if you aren't doing things the boost-build way and are instead a config-per-directory way your basically considered a second class citizen in spite of that being the way the rest of the oss world works.
Please give a URL to these discussions you are citing. Granted that Boost Build creates output in a different structure than CMake does, where you get the rest of your complaint I do not know.
I don't have a specific discussion so much as the feeling that in discussions leading up to the SC there was a very us against them mentality on the part of people who like boost.build. Its not a very welcoming place to comment as a user/minor bug fix contributor.
It is very hard to adopt a new build system when you get used to the one that exists. It is much like switching from programming from one computer language to another one. People are passionate and tempers often get high.
The fact that it is still non-obvious how to do this without touching anything besides a build directory is awful. This should be somewhere in big bold letters.
Its not like there haven't been concerns about boost.build for years.
All build systems, heck all software, has "concerns".
Yes but the issues that I'm talking about are things that have been an issue for years and never got fixed. See also silently dropping flags if you use a space and don't quote in bjam files (something also not obvious and yet important to pass compiler flags!). At least CMAKE/most sane build systems will put up errors somewhere along the lines.
Are these so-called issues documented anywhere in Boost Trac ? Have PRs been created for these issues ? Have these issues been discussed on the Boost mailing lists ? If so, please cite where.
I have no idea, but I know that they come up enough that build questions are pretty persistent on stack overflow compared to other c++ software in my opinion. Boost has by far the hardest to understand system as a user of anything I've dealt with, including setting up cross compiling gcc which is no picnic. I have seen the whitespace issue dismissed as intended behavior because of the way the lexer works in a thread at one point, but its an intended behavior that is very user unfriendly.
The solution is always to raise issues and if there is no response than you have a right to be ticked off. I do agree with you that for many, if not most, programmers Boost Build is arcane. But it actually works with much less amount of scripting work required than CMake does. Nonetheless I agree with the move to CMake, as much as I hope Boost Build still remains as an alternative for end-users who also like using it.
Its not like the documentation for boost.build wasn't basically "ask the mailing list or prey someone else has asked stack overflow" for years.
The documentation is bad compared to what other documentation?
The documentation is bad compared to say, CMAKE, which isn't great in the first place.
CMake docs are just a list of various subjects without any overviews of how to use anything. I do not call that better than Boost Build, and I do not thing that Boost Build documentation is great either. Yes but plenty of people have written CMake tutorials. Boost.build not so much.
Tutorials may not be for everyone as a way of understanding the basic CMake concepts and how they relate to each other. I specifically have to understand concepts and their relationship before I even want to look at tutorials. I will almost certainly end up buying the CMake book in order to understand it.
Setting up an out of build directory has always been a pain with poorly documented flags needing to be invoked to share a common source directory (and its worth noting that I'm not sure its technically parallel safe in any reasonable way given the need to bootstrap and create header links and what not).
Its not like every time a new version of MSVC beta comes out boost.build doesn't break and its not a priority because the maintainers of boost.build don't use MSVC.
Prove that it wasn't a priority. Considering that the last Boost release was delayed precisely to support MSVC building.
It was delayed to support the final release. CMAKE supported it from the first beta. Given that MSVC is specifically making an effort to implement features to be part of the standards process, this is basically a choice between using boost or being on MSVC's and C++ cutting edge. Support for MSVC has basically always been this bad as far as I remember. It should have never been necessary to delay a release to support a key platform when there were four betas.
Four betas that were in constant flux but you think that it is up to Boost to constantly follow VC++'s changes as they roll out a new release over an extended time period. Boost has constantly gone out of its way to accommodate Microsoft and VC++. Any breakage that occurs is because VC++ has always been behind gcc and clang as far as C++ standards compliance. Needless to say the VC++ preprocessor has never been C++ standards compliant and lack of such things like two-phase lookup has repeatedly broken C++ standards compliance in the sort of corner cases which advanced C++ code as evidenced by Boost libraries entails. You are way out of line on this item. If you had any real knowledge of Boost library code you would know that the vast majority of one-off fixes are for the VC++ compilers. That has certainly improved with the latest VC++ release(s), but to say that Boost does not and has not gone out of its way tro accommodate VC++ is just wrong.
Honestly standards compliance errors are great, I can fix those locally. If I could persistently get to those I would be happy. What has always been a problem is when feature detection or compiler detection goes wrong, and everything blows up before I even get a chance to find real errors.
You should report these problems with [config] starting your subject as this as feature detection is the essence of the Boost config library.
This is a design flaw. If MSVC next version comes out, I should at least be able to try to build what worked last version.
I run local tests of various Boost libraries using VC++8.0 through the latest VC++14.1. I have never run into a configuration problem of which I am aware as reflected by those tests. If you have problems doing this with any Boost library you should report it.
AMDG On 07/27/2017 12:42 PM, Gary Furnish via Boost wrote:
I have seen the whitespace issue dismissed as intended behavior because of the way the lexer works in a thread at one point, but its an intended behavior that is very user unfriendly.
I would love to fix the whitespace issue. Unfortunately, in addition to breaking the world, it would cause just as many problems as it would solve. i.e. Instead of getting an incomprehensible error message when you forget a space, you'll get an incomprehensible error message when you forget to use quotes, instead. In Christ, Steven Watanabe
AMDG On 07/27/2017 09:28 AM, Gary Furnish via Boost wrote:
. Sure. See the discussions where if you aren't doing things the boost-build way and are instead a config-per-directory way your basically considered a second class citizen in spite of that being the way the rest of the oss world works. The fact that it is still non-obvious how to do this without touching anything besides a build directory is awful. This should be somewhere in big bold letters.
$ b2 --help ... --build-dir=DIR Build in this location instead of building within the distribution tree. Recommended! This option is also documented here: http://www.boost.org/more/getting_started/windows.html#invoke-b2 and here: http://www.boost.org/build/doc/html/bbv2/overview/invocation.html#bbv2.overv... In Christ, Steven Watanabe
I was referring to the need to --ignore-site-config --user-config=build_directory/user_config.jam --build-dir=build_directory --stage-dir=build_directory/stage combo to replicate configure-like per directory settings. --user-config and --ignore-site-config are undocumented, I think --stage_directory is documented somewhere but not in most places, and figuring out that you need to combine all four is difficult to say the least. On Thu, Jul 27, 2017 at 3:16 PM, Steven Watanabe via Boost <boost@lists.boost.org> wrote:
AMDG
On 07/27/2017 09:28 AM, Gary Furnish via Boost wrote:
. Sure. See the discussions where if you aren't doing things the boost-build way and are instead a config-per-directory way your basically considered a second class citizen in spite of that being the way the rest of the oss world works. The fact that it is still non-obvious how to do this without touching anything besides a build directory is awful. This should be somewhere in big bold letters.
$ b2 --help ... --build-dir=DIR Build in this location instead of building within the distribution tree. Recommended!
This option is also documented here: http://www.boost.org/more/getting_started/windows.html#invoke-b2
and here: http://www.boost.org/build/doc/html/bbv2/overview/invocation.html#bbv2.overv...
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I) Accept proposals for new boost tools into the review queue. Such tools might be just Cmake templates or things like that. Encourage members of the developer's list to submit proposals to support efforts by library developers to (for example): a) CMake for building and testing libraries b) Creation of Find(library) to help boost users who use CMake c) Creation of CMakePackage(Library) (actually I don't know what this is but it has been mentioned. d) Addition of continuation integration testing via appveyor, travis or whatever Note that above ideas would be likely installed on a library by library basis. Also note that above ideas not much dependent upon each other. There is not requirement that they be installed all at once. Such proposals would be added to the "Boost proposal review queue" and be addressed via a similar procedure to that used to decide acceptance of proposed libraries. Since most of these proposals take the form of "best", "suggested" or "required" practices they would take the form of explicit requirements and procedures described in a document in a common format. This document would be posted as part of the Boost web page. Obviously, such proposals would have to be specific enough for library developers to "paste in" or otherwise implement without a lot of investment of effort. In the past, Naill posted his "best practices" and I've made my own personal recommendations on the boost library incubator pages, but these don't have any "official" acceptance. The above would build consensus for what we might think of as boost best practices, boost requirements, or something like that. II) Accept proposals for new boost tools. These would be code. There are already a few tools such as bcp, boost dependency analysis, library_test and perhaps others. I propose that tool proposals be accepted and reviewed just as libraries are. Examples of things I would like to see coming out of this might be: a) better discussion and concensus on what "Dependency" means in the context of boost libraries and a tool which reflects that concensus. e) Dashboard for test results from CI systems similar to or perhaps integrated into the current test matrix. Actually, I would like to see this dashboard include tests run by users similar to the way that CTest/CDash is supposed to work. f) Serious enhancements to existing tools. Of course proposals for such tools would have to include (mostly) working code so that a proposal can be actually evaluated. Note that the above focuses on evaluating specific proposals which are (more or less) ready to implement. There's not much point in spending a lot of time discussing ideas which have yet to arrive to this stage of development I had a lot to say about all this in my boost 2.0 presentation at CPPNow back in 2015. Unfortunately, the presentation wasn't recorded but the slides are available at http://rrsd.com/software_development/boost/C++Now2015/index.html Robert Ramey
On Tue, Jul 18, 2017 at 6:12 AM, Jon Kalb via Boost <boost@lists.boost.org> wrote:
Therefore, we, the Steering Committee, announce...our...intent to move Boost’s build system to CMake for users and developers alike.
I've been following the CMake threads and clearly it is a divisive issue with folks taking up positions on both sides of the debate. However, here's a smaller problem which I think we should just address without endless debate: 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> Chatter on the mailing list suggests these might be of great assistance: <https://github.com/pdimov/boost-cmake-demo> <https://github.com/pdimov/boost-cmake-demo-2> Perhaps the Steering Committee could focus on this smaller, worthwhile goal to move us forward and in the process get valuable experience that will help with the larger decisions? I don't want endless emails and talk though, I'd like to get Beast into 1.66.0 Thanks!
I would like to thank the Steering Committee for making this decision. I realize it has been a contentious one. On Tue, Jul 18, 2017 at 6:12 AM, Jon Kalb via Boost <boost@lists.boost.org> wrote: <snip>
The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective.
Jon has identified here my greatest concern with our use of bjam: that it represents a barrier to adoption of Boost. I'm often in the position of advocating for Boost, and I find it very difficult to explain to potential users why it has its own, fairly obscure (though arguably superior) build system instead of one of the ones commonly used in the industry. Worse, bjam compounds the reputation of Boost as accessible only to gurus. It saddens me to see that this decision has alienated some of our valuable contributors. I hope they will come to see that moving to a more familiar infrastructure will draw in new users and provide a needed jolt of momentum to the use of our libraries. In the meantime, I volunteer to help with the CMake conversion! Best Regards, Jeff
participants (49)
-
Alain Miniussi -
Andrey Semashev -
Artyom Beilis -
Barrett Adair -
Chris Glover -
Daniel James -
Daniela Engert -
David Sankel -
David Stone -
Deniz Bahadir -
Edward Diener -
Florent Castelli -
Gary Furnish -
Gavin Lambert -
Ion Gaztañaga -
Jared Grubb -
Jason Roehm -
Jeff Trull -
JeremyAgost -
John Maddock -
John McFarlane -
Jon Kalb -
Klemens Morgenstern -
Louis Dionne -
Mateusz Loskot -
Niall Douglas -
Olaf van der Spek -
Oliver Kowalke -
P F -
paul
-
Paul A. Bristow -
Paul Mensonides -
Peter Dimov -
Raffi Enficiaud -
Rene Rivera -
rleigh＠codelibre.net -
Robert -
Robert Ramey -
Roger Leigh
-
Sergei Nikulov -
Stefan Seefeld -
Steve Robbins -
Steven Watanabe -
Thomas Heller -
Thorsten Ottosen -
Tom Westerhout -
Vinnie Falco -
Vladimir Prus -
Zach Laine