[boost] Switch to CMake -- Analysis

[Thomas Heller via Boost]

Hi list,

After there has been a heated debated over the last three days over the
switch to CMake, I'd like to share my observations...

First of all, a general observation: In this discussion, there generally
seems to two camps: Those who know Boost.Build and those who know CMake.
Unfortunately, there doesn't seem to be any overlap between those
groups, which generally made the discussions about a potential switch to
CMake unfruitful, often leading to misunderstandings due to a lack of
knowledge about the other tool. There is no doubt, that the group of
people knowing CMake is larger and that projects using CMake far
outnumber the ones using Boost.Build. A thousand flies can't be wrong,
right? Is the popularity of CMake really the only benefit?

Here is the thing, from my point of view: Apart from the different
philosophy (Build System vs. Build System generator), in the end, you
get a executable/library out of the system. From a pragmatic point of
view, the only thing that changes to develop/build/test/use a library is
the work flow. Leaving aside the disruptive and its effects of such.

[...] our build system has become an impediment for many developers
and users, existing and prospective.

Let's look at users first. Yes, FindBoost.cmake has its problems, but it
works in 90% of the cases (from my own experience). This can, and should
certainly be improved. Providing the necessary XXX-config.cmake files is
what fixes this. There has been movement in that direction, with code,
which could be just improved upon. This will fix those cases. The other
group of library consumers, expressed the urge to build boost directly
as part of their build process. That hasn't been done yet, but I am
pretty certain, there are no road blocks to actually write such a CMake
Module, which invokes b2 instead of the compiler directly inside of the
superproject. Together with the generated XXX-config.cmake files, this
use case is covered. From my recollection of the various discussions,
this approach was not contentious at all, it wouldn't even require
interaction with all library maintainers, and all CMake users (existing
or prospective) would immediately benefit.

Now on to developers. There is obviously a lot of resistance from
existing developers (for various reasons, which are not really relevant
for the discussion at hand). In my opinion, maintaining two build
systems is a no-go. Either make a clear cut, or don't. Please don't
waste resources on maintaining and supporting both. With this line of
thought as the background, this will create massive disruption.
Switching the whole of boost (including infrastructure, documentation
etc.) to be built and tested with CMake is not easy and take a lot of
time, leaving a void for both maintainers and prospective boost library
authors.

Now, the argument that has been brought up very often in favor for the
switch is that it will attract more contributors, but will it really?
I am reluctant to the idea that people don't contribute new libraries to
boost just because of the build system. Despite a switch to cmake, you'd
still have to conform to Boost.CMake guidelines and somehow make your
library buildable and testable within and outside of the Boost Tree
(there might be a straight forward solution to this).
Furthermore, I often hear something like "in the presence of GitHub and
CMake people don't think about submitting to boost anymore". This is
exactly the point. But it has nothing to do with the "and CMake" suffix.
It's is just far more easier and convenient to drop you library to
GitHub, advertise it on various channels and call it a day. I hear you
say: "Sure, but libraries will only be adopted if they come with CMake."
That might very well be true, but what has this to do with Boost?
Compare the lengthy and exhausting review process you have to go through
with the click of a few buttons and hammering something onto a keyboard.
And no, Robert, while the incubator was a nice idea, it doesn't
compensate that either ;)

All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config). While your add it, improve Boost.Build, maybe it can rise
again from its ashes (why did it "fail" in the first place?).

Regards,
Thomas

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

[paul via Boost]

Post by Thomas Heller via Boost
Hi list,
After there has been a heated debated over the last three days over the
switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally
seems to two camps: Those who know Boost.Build and those who know CMake.
Unfortunately, there doesn't seem to be any overlap between those
groups, which generally made the discussions about a potential switch to
CMake unfruitful, often leading to misunderstandings due to a lack of
knowledge about the other tool. There is no doubt, that the group of
people knowing CMake is larger and that projects using CMake far
outnumber the ones using Boost.Build. A thousand flies can't be wrong,
right? Is the popularity of CMake really the only benefit?
Here is the thing, from my point of view: Apart from the different
philosophy (Build System vs. Build System generator), in the end, you
get a executable/library out of the system. From a pragmatic point of
view, the only thing that changes to develop/build/test/use a library is
the work flow. Leaving aside the disruptive and its effects of such.

[...] our build system has become an impediment for many developers
and users, existing and prospective.

Let's look at users first. Yes, FindBoost.cmake has its problems, but it
works in 90% of the cases (from my own experience). This can, and should
certainly be improved. Providing the necessary XXX-config.cmake files is
what fixes this. There has been movement in that direction, with code,
which could be just improved upon. This will fix those cases. The other
group of library consumers, expressed the urge to build boost directly
as part of their build process. That hasn't been done yet, but I am
pretty certain, there are no road blocks to actually write such a CMake
Module, which invokes b2 instead of the compiler directly inside of the
superproject. Together with the generated XXX-config.cmake files, this
use case is covered. From my recollection of the various discussions,
this approach was not contentious at all, it wouldn't even require
interaction with all library maintainers, and all CMake users (existing
or prospective) would immediately benefit.
Now on to developers. There is obviously a lot of resistance from
existing developers (for various reasons, which are not really relevant
for the discussion at hand). In my opinion, maintaining two build
systems is a no-go. Either make a clear cut, or don't. Please don't
waste resources on maintaining and supporting both. With this line of
thought as the background, this will create massive disruption.
Switching the whole of boost (including infrastructure, documentation
etc.) to be built and tested with CMake is not easy and take a lot of
time, leaving a void for both maintainers and prospective boost library
authors.
Now, the argument that has been brought up very often in favor for the
switch is that it will attract more contributors, but will it really?
I am reluctant to the idea that people don't contribute new libraries to
boost just because of the build system. Despite a switch to cmake, you'd
still have to conform to Boost.CMake guidelines and somehow make your
library buildable and testable within and outside of the Boost Tree
(there might be a straight forward solution to this).
Furthermore, I often hear something like "in the presence of GitHub and
CMake people don't think about submitting to boost anymore". This is
exactly the point. But it has nothing to do with the "and CMake" suffix.
It's is just far more easier and convenient to drop you library to
GitHub, advertise it on various channels and call it a day. I hear you
say: "Sure, but libraries will only be adopted if they come with CMake."
That might very well be true, but what has this to do with Boost?
Compare the lengthy and exhausting review process you have to go through
with the click of a few buttons and hammering something onto a keyboard.
And no, Robert, while the incubator was a nice idea, it doesn't
compensate that either ;)
All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config).

pkg-config is build-indenpendent so can be consumed by meson and bazel.



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

[Thomas Heller via Boost]

Post by Thomas Heller via Boost
All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config).

pkg-config is build-indenpendent so can be consumed by meson and bazel.

It's also consumable by cmake. Doesn't propagate build properties though.
Only plain and simple strings on how to invoke the compiler/linker.
Anything else is not the default behavior.

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

[Andrey Semashev via Boost]

Post by paul via Boost

Post by Thomas Heller via Boost
All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config).

pkg-config is build-indenpendent so can be consumed by meson and bazel.
It's also consumable by cmake. Doesn't propagate build properties though.
Only plain and simple strings on how to invoke the compiler/linker.
Anything else is not the default behavior.

It does, at least with regard to macros to define, include/library
directories to add and libraries to link with. Or do you have different
properties in mind?

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

[Thomas Heller via Boost]

Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" <

Post by paul via Boost

Post by Thomas Heller via Boost
All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config).

pkg-config is build-indenpendent so can be consumed by meson and bazel.
It's also consumable by cmake. Doesn't propagate build properties though.
Only plain and simple strings on how to invoke the compiler/linker.
Anything else is not the default behavior.

It does, at least with regard to macros to define, include/library
directories to add and libraries to link with. Or do you have different
properties in mind?


Well, recently, cmake got support for c++ feature properties for example.
The big advantage is that the flags carry on semantics and the build system
is able to determine conflicts etc.



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

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

[paul via Boost]

Post by Thomas Heller via Boost
Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" <

Post by paul via Boost

Post by Thomas Heller via Boost
All in all, I am pretty confident that a disruptive switch will hurt
Boost more than it brings benefit. This already happened. To come to an
end and summarize: Provide proper CMake integration, such that Boost is
consumable by those (while you are at it, don't forget meson, bazel and
pkg-config).

pkg-config is build-indenpendent so can be consumed by meson and bazel.
It's also consumable by cmake. Doesn't propagate build properties though.
Only plain and simple strings on how to invoke the compiler/linker.
Anything else is not the default behavior.

It does, at least with regard to macros to define, include/library
directories to add and libraries to link with. Or do you have different
properties in mind?
Well, recently, cmake got support for c++ feature properties for example.
The big advantage is that the flags carry on semantics and the build system
is able to determine conflicts etc.

Well I think you can encode those using pkg-config files. You can use the
`replaces` and `conflicts` fields to help pkg-config resolve the flag. The C++
features properties still lack maturity with cmake.

Post by Thomas Heller via Boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman
/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
st

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

[Gavin Lambert via Boost]

Post by Thomas Heller via Boost
It's also consumable by cmake. Doesn't propagate build properties though.
Only plain and simple strings on how to invoke the compiler/linker.
Anything else is not the default behavior.

pkg-config can propagate whatever arbitrary string variables you like,
though obviously the caller then has to know to ask for them (you can
get a list of all defined variables, though).


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

[Groke, Paul via Boost]

-----Original Message-----
Heller via Boost
Sent: Freitag, 21. Juli 2017 16:21
Subject: [boost] Switch to CMake -- Analysis

...

Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in
90% of the cases (from my own experience). This can, and should certainly
be improved. Providing the necessary XXX-config.cmake files is what fixes
this. There has been movement in that direction, with code, which could be
just improved upon. This will fix those cases. The other group of library
consumers, expressed the urge to build boost directly as part of their build
process. That hasn't been done yet, but I am pretty certain, there are no
road blocks to actually write such a CMake Module, which invokes b2 instead
of the compiler directly inside of the superproject. Together with the
generated XXX-config.cmake files, this use case is covered. From my
recollection of the various discussions, this approach was not contentious at
all, it wouldn't even require interaction with all library maintainers, and all
CMake users (existing or prospective) would immediately benefit.

+1
I like this approach very much!

Just to check if I understand correctly: When you write "CMake Module, which invokes b2 instead of the compiler directly", do you mean a CMake Module which would also be able to generate the Jamfile, or would all Boost library authors/maintainers still have to manually write the Jamfile? Because if you meant the latter, do you think that the former would be possible?


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

[Thomas Heller via Boost]

Am 21.07.2017 5:15 nachm. schrieb "Groke, Paul via Boost" <

-----Original Message-----
Heller via Boost
Sent: Freitag, 21. Juli 2017 16:21
Subject: [boost] Switch to CMake -- Analysis

...

Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in
90% of the cases (from my own experience). This can, and should certainly
be improved. Providing the necessary XXX-config.cmake files is what fixes
this. There has been movement in that direction, with code, which could be
just improved upon. This will fix those cases. The other group of library
consumers, expressed the urge to build boost directly as part of their build
process. That hasn't been done yet, but I am pretty certain, there are no
road blocks to actually write such a CMake Module, which invokes b2 instead
of the compiler directly inside of the superproject. Together with the
generated XXX-config.cmake files, this use case is covered. From my
recollection of the various discussions, this approach was not

contentious at

all, it wouldn't even require interaction with all library maintainers, and all
CMake users (existing or prospective) would immediately benefit.

+1
I like this approach very much!

Just to check if I understand correctly: When you write "CMake Module,
which invokes b2 instead of the compiler directly", do you mean a CMake
Module which would also be able to generate the Jamfile, or would all Boost
library authors/maintainers still have to manually write the Jamfile?
Because if you meant the latter, do you think that the former would be
possible?


I mean the latter. Using the existing jamfiles. I don't see value in
replacing the already existing ones with auto generated so I haven't
thought about it.



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

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

[Stefan Seefeld via Boost]

Post by Thomas Heller via Boost
Hi list,
After there has been a heated debated over the last three days over the
switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally
seems to two camps: Those who know Boost.Build and those who know CMake.

Mostly, yes. And in addition, people are very polarized (even more so as
a result of this ongoing discussion). So to frame the question as
"should we stay with Boost.Build or should we move to CMake" is
extremely counter-productive.

We need a way to continue to draw from the wealth of expertise encoded
in the existing Boost.Build infrastructure as well as the community
around it, while at the same time being open to change (in general, not
just towards alternative build tools). To invoke a higher authority to
decide to get out of this stalemate is foolish, as it entirely ignores
both how Open Source works in general (you can't coerce people into
doing things they aren't motivated to do to begin with), as well as the
real reason for the stalemate: it's due to an artificial dichotomy:
either Boost.Build or CMake, globally, for everyone at once.

Here is (once again) how I would approach this instead:

* Improve the existing Boost.Build infrastructure to allow libraries to
be built stand-alone. (I remember from discussing with Rene a year ago
that he had some work in progress to achieve this, so I don't think this
is particularly hard, at least not for someone understanding Boost.Build
internals).
* Replace the top-level build logic to simply iterate over all
libraries, invoking this stand-alone build logic.
* With the above in place, it becomes possible to switch from
Boost.Build to CMake one library at a time, so the original question can
be reframed as "which library wants to switch from Boost.Build to
CMake", which, I'm sure, will be much less disruptive (if at all) and
non-controversial, as the people to decide will be project maintainers
and communities.


Does this process appeal to anyone ?

Regards,
Stefan

[Vinnie Falco via Boost]

On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
Does this process appeal to anyone ?

It sounds reasonable in theory, but I think the first thing that
should be addressed is the use-case where Users of Boost who have
pre-built binaries are able to easily consume Boost in their projects
with support from within Boost itself and not the FindBoost.cmake that
comes with CMake which is perpetually behind the latest Boost version.
I'm talking about this:

CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message):
Imported targets not available for Boost version
Call Stack (most recent call first):
cmake/share/cmake-3.8/Modules/FindBoost.cmake:866
(_Boost_COMPONENT_DEPENDENCIES)
cmake/share/cmake-3.8/Modules/FindBoost.cmake:1457 (_Boost_MISSING_DEPENDENCIES)
CMakeLists.txt:67 (find_package)
<https://travis-ci.org/vinniefalco/Beast/jobs/255894286#L1385>

Fixing this seems entirely non-controversial. It doesn't displace
Boost.Build, it adds something that users clearly want (for example, I
want this myself), it enhances the value of Boost and it does so in a
non-intrusive way.

And some work has already been done on this...if the Steering
Committee is going make proclamations why don't they start with this
instead of turning members of the Boost developer community against
each other?

Thanks

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

[Stefan Seefeld via Boost]

Post by Vinnie Falco via Boost
On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
Does this process appeal to anyone ?

It sounds reasonable in theory, but I think the first thing that
should be addressed is the use-case where Users of Boost who have
pre-built binaries are able to easily consume Boost in their projects
with support from within Boost itself and not the FindBoost.cmake that
comes with CMake which is perpetually behind the latest Boost version.

You are talking about a use-case involving a Boost *binary* package. How
is this related to how Boost is built, i.e. how such binaries are
produced ? It seems to me that to provide a tool that can discover
compiler flags needed to build with an existing Boost *binary*
installation is quite trivial to come up with, even if this requires
some additional metadata to be added to Boost installations.
(The really hard use-case, which I'd prefer to dismiss as impossible, is
to enable users to "consume" Boost *sources*, i.e. to integrate a Boost
build into a user's build process. While I'm not opposed to such an
idea, I don't want to have to support it explicitly.)

Stefan

[Vinnie Falco via Boost]

On Fri, Jul 21, 2017 at 9:15 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
You are talking about a use-case involving a Boost *binary* package. How
is this related to how Boost is built, i.e. how such binaries are
produced ?

It is not related to building Boost but it solves something that
annoys a non-zero percentage of Boost users who use CMake. Its not
"moving the build system to cmake" but its step forward.

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

[Stefan Seefeld via Boost]

Post by Vinnie Falco via Boost
On Fri, Jul 21, 2017 at 9:15 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
You are talking about a use-case involving a Boost *binary* package. How
is this related to how Boost is built, i.e. how such binaries are
produced ?

It is not related to building Boost but it solves something that
annoys a non-zero percentage of Boost users who use CMake.

Then *please* let's not add unrelated points to the discussion, for the
sake of getting a handle of what problems we have to solve, and how.

Stefan

[Vinnie Falco via Boost]

On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
Then *please* let's not add unrelated points to the discussion, for the
sake of getting a handle of what problems we have to solve, and how.
Imported targets not available for Boost version

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

[Thomas Heller via Boost]

Am 21.07.2017 6:42 nachm. schrieb "Vinnie Falco via Boost" <
***@lists.boost.org>:

On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost
Then *please* let's not add unrelated points to the discussion, for the
sake of getting a handle of what problems we have to solve, and how.
Imported targets not available for Boost version

It's a symptom of the problem. It is off topic in the regard that insisting
that the problem exists won't make it go away.


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

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

[Andrey Semashev via Boost]

Post by Stefan Seefeld via Boost
* Improve the existing Boost.Build infrastructure to allow libraries to
be built stand-alone. (I remember from discussing with Rene a year ago
that he had some work in progress to achieve this, so I don't think this
is particularly hard, at least not for someone understanding Boost.Build
internals).
* Replace the top-level build logic to simply iterate over all
libraries, invoking this stand-alone build logic.
* With the above in place, it becomes possible to switch from
Boost.Build to CMake one library at a time, so the original question can
be reframed as "which library wants to switch from Boost.Build to
CMake", which, I'm sure, will be much less disruptive (if at all) and
non-controversial, as the people to decide will be project maintainers
and communities.
Does this process appeal to anyone ?

I'm sure it's been mentioned before by someone, but as a Boost user and
packager (for my work projects) I don't want to deal with a dozen of
build systems (worse yet - multiple versions of the same build system)
to be able to build Boost. Having a single build system, a single
interface and customization point is an important advantage regardless
of what the actual build system is used.

Besides, I have my doubts regarding the technical feasibility of this
heterogenous infrastructure as well. I'm sure there will be quirks and
points of incompatibiliy between the different build systems or some
seemingly unreasonable limitations that follow from this integration
that will leave someone, possibly users, unhappy.

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

[Stefan Seefeld via Boost]

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost
* Improve the existing Boost.Build infrastructure to allow libraries to
be built stand-alone. (I remember from discussing with Rene a year ago
that he had some work in progress to achieve this, so I don't think this
is particularly hard, at least not for someone understanding Boost.Build
internals).
* Replace the top-level build logic to simply iterate over all
libraries, invoking this stand-alone build logic.
* With the above in place, it becomes possible to switch from
Boost.Build to CMake one library at a time, so the original question can
be reframed as "which library wants to switch from Boost.Build to
CMake", which, I'm sure, will be much less disruptive (if at all) and
non-controversial, as the people to decide will be project maintainers
and communities.
Does this process appeal to anyone ?

I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.

Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later). I'm merely pointing out that rather then switching
from Boost.Build to CMake atomically, we should attempt to do this
piece-wise (and allow projects to keep the current logic if they
prefer), which means supporting *two* build systems, not "a dozen".
I'm really trying hard to come up with *practical* proposals to get out
of the current stalemate. But replies like the above don't help at all.

Post by Andrey Semashev via Boost
Besides, I have my doubts regarding the technical feasibility of this
heterogenous infrastructure as well. I'm sure there will be quirks and
points of incompatibiliy between the different build systems or some
seemingly unreasonable limitations that follow from this integration
that will leave someone, possibly users, unhappy.

So you think we can't transition one library at a time, but you believe
it will be possible to do a switch for 100+ libraries synchronously ?
Sorry, but I can't follow your reasoning...

Stefan

[Andrey Semashev via Boost]

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.
Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later).

I think you did advocate for the model where each library picks its own
tools, including the build system. Allowing two build systems would be
just the first step. I'm just saying that this won't work well for Boost
users, at least not for a significant part of them.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
Besides, I have my doubts regarding the technical feasibility of this
heterogenous infrastructure as well. I'm sure there will be quirks and
points of incompatibiliy between the different build systems or some
seemingly unreasonable limitations that follow from this integration
that will leave someone, possibly users, unhappy.

So you think we can't transition one library at a time, but you believe
it will be possible to do a switch for 100+ libraries synchronously ?
Sorry, but I can't follow your reasoning...

I wasn't referring to the transition process but rather the resulting
model adopted by Boost. If that model includes multiple build systems
then it is bound to have problems stemming from the integration.

Regarding the transition process (to whatever build system, not
necessarilly CMake), I think both ways have its merits. Making a
whole-Boost switch is more resource expensive, but not impossible if
there are enough interested people with enough permissions to do the
job. A step by step switch adds a period (potentially, open-ended) when
people have to maintain both build systems. As a Boost developer, I'm
not happy about that. As a user, I might not be happy either, if one of
the build systems doesn't actually work in a Boost release.

Regarding CMake as a candidate build system, I'm not convinced that the
switch would benefit Boost in terms of "new blood" or something. I don't
think the build system is something that is keeping millions of
developers out there from contributing to Boost, as being advertised. It
might be one, though probably not the major point, but I don't think
anything will change e.g. wrt. maintenance if we switch right now. Most
of the work doesn't even touch the build system or comes down to copying
and pasting a piece of jamfile.

I recognize that CMake has gained popularity and it is easier to find
support for it online. But I know that more than once I've been puzzled
about how to do one thing or the other in it, much like with
Boost.Build. So as a Boost developer, there may be a slight plus on
CMake side for me, but absolutely not worth the damage that has been
inflicted on Boost already on the road to it. As a Boost user I really
don't care as I never ever integrate third party projects into my
project build system as I consider that a broken approach in the first
place.

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

[Andrey Semashev via Boost]

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.
Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later).

I think you did advocate for the model where each library picks its own
tools, including the build system. Allowing two build systems would be
just the first step. I'm just saying that this won't work well for Boost
users, at least not for a significant part of them.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
Besides, I have my doubts regarding the technical feasibility of this
heterogenous infrastructure as well. I'm sure there will be quirks and
points of incompatibiliy between the different build systems or some
seemingly unreasonable limitations that follow from this integration
that will leave someone, possibly users, unhappy.

So you think we can't transition one library at a time, but you believe
it will be possible to do a switch for 100+ libraries synchronously ?
Sorry, but I can't follow your reasoning...

I wasn't referring to the transition process but rather the resulting
model adopted by Boost. If that model includes multiple build systems
then it is bound to have problems stemming from the integration.
Regarding the transition process (to whatever build system, not
necessarilly CMake), I think both ways have its merits. Making a
whole-Boost switch is more resource expensive, but not impossible if
there are enough interested people with enough permissions to do the
job. A step by step switch adds a period (potentially, open-ended) when
people have to maintain both build systems. As a Boost developer, I'm
not happy about that. As a user, I might not be happy either, if one of
the build systems doesn't actually work in a Boost release.
Regarding CMake as a candidate build system, I'm not convinced that the
switch would benefit Boost in terms of "new blood" or something. I don't
think the build system is something that is keeping millions of
developers out there from contributing to Boost, as being advertised. It
might be one, though probably not the major point, but I don't think
anything will change e.g. wrt. maintenance if we switch right now. Most
of the work doesn't even touch the build system or comes down to copying
and pasting a piece of jamfile.
I recognize that CMake has gained popularity and it is easier to find
support for it online. But I know that more than once I've been puzzled
about how to do one thing or the other in it, much like with
Boost.Build. So as a Boost developer, there may be a slight plus on
CMake side for me, but absolutely not worth the damage that has been
inflicted on Boost already on the road to it. As a Boost user I really
don't care as I never ever integrate third party projects into my
project build system as I consider that a broken approach in the first
place.

Actually, as a user I do care and not in favor of CMake because there is
always a possibility that Boost requires a newer CMake version that is
not available on my platform.

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

[Chris Glover via Boost]

On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost <

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there is
always a possibility that Boost requires a newer CMake version that is
not available on my platform.

You'll also need whatever version of the *actual* build system CMake is
generating for. So, we go from having 0 dependencies to at least 2: CMake
itself, and the target build system.

-- chris

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

[Artyom Beilis via Boost]

On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost

Post by Chris Glover via Boost
On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost <
You'll also need whatever version of the *actual* build system CMake is
generating for. So, we go from having 0 dependencies to at least 2: CMake
itself, and the target build system.
-- chris

I think this exactly summarizes both advantage and Achilles heel of Boost.Build
and the entire vision of Boost Community.
------------------------------------------------------------------------

Boost.Build is ok for 100% self contained library that needs nothing but
itself and boost.

This why declarative approach of BB actually works not bad and you can run
from single line build of multiple variants.

However the REAL WORLD isn't that "perfect". In real world scenarios boost
libraries require complex configuration and depend on 3rd part libraries.

This requires complex configuration - search for libraries, headers running
some checks. This makes BB declarative/tags approach programming
nightmare.

As the author of Boost.Locale library that has complex dependencies and
build options I can say it is impossible to maintain complex projects with BB.

Why:

1. Support of basic features given by any normal REAL WORLD build
system barely exists (library search configuration options etc)
2. Documentation isn't good and it was this for years.
3. Knowledge exits only for few people.

Do you want a proof? Please find me a tutorial how to search a 3rd
part library or complete
reference documentation for that.

I mean:

(a) find if library exists (with optional search path)
(b) find if headers exists (with optional search path)
(c) given this turn on and off some feature of fail library build
(d) propagate results to tests.

And this is one of the most basic and trivial feature that exists in every
real world build system.

And now take a look on this code:

https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L124

Lines 124-145 this is how I search ICU for Boost.Locale

And this is how it is done in BB:

https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2#L63
Lines 63-190

I look at the code and I can barely understand what is written. Options
that are in use aren't documented. And only very few people
on this list can describe me what is going on.

So please all of you complaining how Boost.Build is great in comparisons
to cmake and what cmake can't do. I want you to tell what BB can't do?
It can't support complex projects that aren't self contained properly.

I want also relate to another issue that was pointed there?

That CMake can't run

./b2 toolset=msvc-12,msvc-14,mingw

Boost.Build can't either once a 3rd part library required as search paths
for each need to be different. What about running?

./b2 -sICU_PATH=/opt/icu56 ..
./b2 -sICU_PATH=/opt/icu59 ..

And this is one of the principle issues of BB - its declarative way
of providing configuration.

---------

So I'm really thrilled by moving to CMake, not because it is perfect
build system - it isn't. But at least it (a) feature rich (b) well documented
(c) it works for many cases BB would required custom build macros

So instead of trying to live in pure world without dependencies please
consider thous who can't afford it.

Artyom Beilis

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

[Roger Leigh via Boost]

On 21/07/17 20:53, Artyom Beilis via Boost wrote:
[...]

Post by Artyom Beilis via Boost
And this is one of the most basic and trivial feature that exists in every
real world build system.
https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L124
Lines 124-145 this is how I search ICU for Boost.Locale

Note that you can further simplify this to a single line:

find_package(ICU COMPONENTS uc data i18n)

and then use the imported targets ICU::uc, ICU::data and ICU::i18n to
link with. Handles all the debug postfixes, alternative library names
on Windows (dt/data, in/i18n) etc. It's basically what you're doing,
but a bit more comprehensive and flexible (by using the imported
targets, you allow for /export/ of the target configuration for use by
end users and downstream components).

This requires FindICU.cmake, which is provided in newer CMake releases.
But it's absolutely possible to copy this into your own project to
support older CMake releases (I do this myself). See
https://cmake.org/cmake/help/v3.9/module/FindICU.html for further details.


Regards,
Roger

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

[Artyom Beilis via Boost]

On Fri, Jul 21, 2017 at 11:14 PM, Roger Leigh via Boost

Post by Roger Leigh via Boost
[...]

Post by Artyom Beilis via Boost
And this is one of the most basic and trivial feature that exists in every
real world build system.
https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L124
Lines 124-145 this is how I search ICU for Boost.Locale

find_package(ICU COMPONENTS uc data i18n)
and then use the imported targets ICU::uc, ICU::data and ICU::i18n to link
with. Handles all the debug postfixes, alternative library names on Windows
(dt/data, in/i18n) etc.
[snip]
This requires FindICU.cmake, which is provided in newer CMake releases. But
it's absolutely possible to copy this into your own project to support older
CMake releases (I do this myself). See
https://cmake.org/cmake/help/v3.9/module/FindICU.html for further details.
Regards,
Roger

You are 100% right except this code dates to days when CMake was about 2.6/2.8.
But indeed it can be updated.

Artyom

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

[Florent Castelli via Boost]

Post by Roger Leigh via Boost
[...]

Post by Artyom Beilis via Boost
And this is one of the most basic and trivial feature that exists in every
real world build system.
https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L124
Lines 124-145 this is how I search ICU for Boost.Locale

find_package(ICU COMPONENTS uc data i18n)
and then use the imported targets ICU::uc, ICU::data and ICU::i18n to
link with. Handles all the debug postfixes, alternative library names
on Windows (dt/data, in/i18n) etc. It's basically what you're doing,
but a bit more comprehensive and flexible (by using the imported
targets, you allow for /export/ of the target configuration for use by
end users and downstream components).

The old form also allows finding the various ICU libraries from
different installations / versions. The COMPONENTS approach doesn't have
that issue.

Post by Roger Leigh via Boost
This requires FindICU.cmake, which is provided in newer CMake
releases. But it's absolutely possible to copy this into your own
project to support older CMake releases (I do this myself). See
https://cmake.org/cmake/help/v3.9/module/FindICU.html for further details.
Regards,
Roger
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Mateusz Loskot via Boost]

Post by Artyom Beilis via Boost
On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost

Post by Chris Glover via Boost
On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost <
You'll also need whatever version of the *actual* build system CMake is
generating for. So, we go from having 0 dependencies to at least 2: CMake
itself, and the target build system.
-- chris

I think this exactly summarizes both advantage and Achilles heel of Boost.Build
and the entire vision of Boost Community.
------------------------------------------------------------------------
[...]
As the author of Boost.Locale library that has complex dependencies and
build options I can say it is impossible to maintain complex projects with BB.
1. Support of basic features given by any normal REAL WORLD build
system barely exists (library search configuration options etc)
2. Documentation isn't good and it was this for years.
3. Knowledge exits only for few people.
Do you want a proof? Please find me a tutorial how to search a 3rd
part library or complete reference documentation for that.

I'd like to second Artyom's comments here.
Boost.GIL may serve as another example - with I/O API depending on
number of external libraries to support raster formats.

Back in 2010, during and long after the GIL review, I remember Christian Henning
(author and maintainer of GIL) and myself, we were having hard times over long
months trying to complete the Boost.Build setup for the library.
I don't remember if eventually Christian released GIL with user
friendly support for
third-party libraries.
I'd been trying to convince myself [1] to like Boost.Build Extensions
[2] for some time.

For several years after, I'd be lurking around the numerous Boost.GIL bugs on
the Trac trying convince myself to pick and work on some, but the Boost.Build
adventure was putting me off, effectively.
Eventually, I gave up looking at GIL completely.

I was involved in Boost.Geometry for quite some time, especially during period
following the review. Since Boost.Geometry does not require any dependencies
Boost.Build configuration was pretty straightforward.
Not for examples [4] and (some) tests though. For those, it turned to easier to
maintain copy of third-party libraries in-source [5]. Boost.GIL
adventure repeated.

In my experience, Boost.Build works great to build...self-contained Boost.

For an ad-hoc/supporting contributor to Boost, Boost.Build often
proved to be hurdle
hard to get over. I think that may be the case for many developers who
have free slot
of time on a Sunday afternoon and want to pick and shoot a bug in a library.
Lucky one, if the library is external dependencies-free.

To defend my position as willing and not as biased against Boost.Build
as it may seem, a while ago I developed Boost.Build plug-in [6] for Qt Creator.


OTOH, I have love-n-hate view on CMake, but I can at least
a) transit knowledge between projects
b) configure build via command line
c) browse huge number of CMake-ified projects on GitHub to learn about
good CMake configurations (CMake docs is a syntax/commands _reference_,
but it is Shit in terms of presenting idiomatic and complex
configurations, best practices,
do's and don'ts, and often outdated Wiki does not help either)


[1] http://mateusz.loskot.net/post/2010/10/17/notes-on-boost-build-for-boost-gil/
[2] https://svn.boost.org/svn/boost/sandbox/tools/build_extensions/
[3] https://github.com/mloskot/boost-gil-workshop/tree/gil-io2-gdal
[4] https://github.com/boostorg/geometry/tree/develop/example/with_external_libs
[5] https://github.com/boostorg/geometry/tree/develop/example/with_external_libs/contrib
[6] https://github.com/mloskot/qt-creator-plugin-boostbuild

Best regards,

[Joseph Van Riper via Boost]

On Fri, Jul 21, 2017 at 1:24 PM Andrey Semashev via Boost <

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there is
always a possibility that Boost requires a newer CMake version that is
not available on my platform.

This, too, concerns me.

b2 builds on everything, and is included in every boost distribution. It
is apparently built with such consideration that I can use it on
ridiculously old versions of gcc without breaking a sweat.

In cyber security, when training individuals, you find yourself using
ridiculously old machines. We need, therefore, to be able to build
software on these old machines.

Watching this decision play out, I have concerns that I won't be able to do
things like build boost on a 10-year-old distribution of debian using
static libraries (so they work on all distributions based on this debian
release), while also building boost for Windows XP on VC++ 2013 in a way
that allows certain projects with fiddly settings compiler properly, yet
still build for other version of Windows on the more recent compilers with
more sane settings.

I fully expect turbulence in the coming conversion to CMake for my
admittedly non-standard setup.

My hope is that this happens in at a measured pace allowing for edge cases
line mine to weigh in without stopping newer fixes and contributions from
entering the distribution.

If there's some way I can set up a series of automated tests, I'd like to
help.

(Yes, observant folks might notice that I've mentioned this before, and
appeared not to follow up... I did actually try to set up automated
testing, but ran into problems, then failed to follow up with anyone about
those problems because I got distracted by my job... but if this is moving
to CMake, I expect I need to help).

- Trey

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

[Zach Laine via Boost]

On Fri, Jul 21, 2017 at 1:47 PM, Joseph Van Riper via Boost <

Post by Joseph Van Riper via Boost
On Fri, Jul 21, 2017 at 1:24 PM Andrey Semashev via Boost <

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there is
always a possibility that Boost requires a newer CMake version that is
not available on my platform.

This, too, concerns me.
b2 builds on everything, and is included in every boost distribution. It
is apparently built with such consideration that I can use it on
ridiculously old versions of gcc without breaking a sweat.

Again, CMake builds everywhere too. The latest version is 7.3MB. I don't
think this particular issue is anything to worry about -- if people still
want a bootstrapping Boost+CMake, it's trivial to do so.

Zach

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

[Andrey Semashev via Boost]

Post by Zach Laine via Boost
On Fri, Jul 21, 2017 at 1:47 PM, Joseph Van Riper via Boost <

Post by Joseph Van Riper via Boost
On Fri, Jul 21, 2017 at 1:24 PM Andrey Semashev via Boost <

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there is
always a possibility that Boost requires a newer CMake version that is
not available on my platform.

This, too, concerns me.
b2 builds on everything, and is included in every boost distribution. It
is apparently built with such consideration that I can use it on
ridiculously old versions of gcc without breaking a sweat.

Again, CMake builds everywhere too. The latest version is 7.3MB. I don't
think this particular issue is anything to worry about -- if people still
want a bootstrapping Boost+CMake, it's trivial to do so.

Downloading and installing binaries from the Internet is not a
recommended practice in Linux world and not only there. In some
environments this is simply not an option. So often you're stuck with
the versions provided with your distro or the versions you build
yourself. Building often pulls other dependencies, which may not be
recent enough, so the amount of work piles up.


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

[Alain Miniussi via Boost]

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there
is always a possibility that Boost requires a newer CMake version that
is not available on my platform.

We could embed the required CMake distribution in boost, compile it, and
use it to build boost ?


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

[Zach Laine via Boost]

On Fri, Jul 21, 2017 at 2:30 PM, Alain Miniussi via Boost <

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there is
always a possibility that Boost requires a newer CMake version that is not
available on my platform.

We could embed the required CMake distribution in boost, compile it, and
use it to build boost ?

That's what I've been trying to say, though apparently not explicitly
enough.

Zach

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

[Jürgen Hunold via Boost]

Hi Alain,

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there
is always a possibility that Boost requires a newer CMake version that
is not available on my platform.

We could embed the required CMake distribution in boost, compile it, and
use it to build boost ?

If Kitware changes CMake's license to the BGL, then yes.

And repeat: CMake does not compile. It is a Meta-Build-System generating files
for the real deal.

Yours,

Jürgen

[Andrey Semashev via Boost]

Post by Jürgen Hunold via Boost
Hi Alain,

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there
is always a possibility that Boost requires a newer CMake version that
is not available on my platform.

We could embed the required CMake distribution in boost, compile it, and
use it to build boost ?

If Kitware changes CMake's license to the BGL, then yes.

Did you mean BSL (Boost Software License)?

Yes, licensing is an issue, too.

Post by Jürgen Hunold via Boost
And repeat: CMake does not compile. It is a Meta-Build-System generating files
for the real deal.

Well, hopefully, it can generate Makefiles for an old enough GNU make,
which should be everywhere, except Windows, which has VS projects... But
yes, having an actual build system is also something to keep in mind.

_______________________________________________
Unsubscribe & other chang

[degski via Boost]

... except Windows, which has VS projects... But yes, having an actual
build system is also something to keep in mind.

Although CMake can build VS-solutions, I don't think that boost should go
this way. Having solutions with multiple projects (and boost will have
many), is a night-mare, in case one (small) thing needs to be changed in
all projects in that solution, good luck, have fun! This is the inherent
weakness of the solutions/projects approach of VS, a linux-style approach
is needed.

IMHO, the only sensible way to use CMake (from the command-line, not the
stupidly limited "IDE") with a (super-)project like boost on windows is to
generate for and use nmake.

degski

[Steven Watanabe via Boost]

AMDG

Post by degski via Boost
IMHO, the only sensible way to use CMake (from the command-line, not the
stupidly limited "IDE") with a (super-)project like boost on windows is to
generate for and use nmake.

The last time I checked, nmake doesn't support parallel
builds, which makes it rather useless.

In Christ,
Steven Watanabe


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

[degski via Boost]

The last time I checked, nmake doesn't support parallel builds, which
makes it rather useless.

It seems (according to kitware
<https://blog.kitware.com/cmake-building-with-all-your-cores/>) that JOM
<http://download.qt.io/official_releases/jom/jom_1_1_2.zip> is the answer
to that.

degski

[Daniela Engert via Boost]

Post by degski via Boost
It seems (according to kitware
<https://blog.kitware.com/cmake-building-with-all-your-cores/>) that JOM
<http://download.qt.io/official_releases/jom/jom_1_1_2.zip> is the answer
to that.

Yet another dependency - yay! With every suggestion on how to get around
deficiencies of CMake when it comes to actually build (and test)
something things are getting more complicated. From my pov as a (almost
daily) tester of both individual Boost libraries and all of Boost in
different configurations, and as a Boost distro maintainer, this sounds
like a growing nightmare when I compare it to the simplicity and
ease-of-use of Boost.Build in those scenarios that I have to deal with.
As an end-user, when it comes to consuming Boost libraries I don't care
if it is Boost.Build, or CMake, or both, or whatever else because we use
neither of them in our team.

Ciao
Dani


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

[Roger Leigh via Boost]

Post by Daniela Engert via Boost

Post by degski via Boost
It seems (according to kitware
<https://blog.kitware.com/cmake-building-with-all-your-cores/>) that JOM
<http://download.qt.io/official_releases/jom/jom_1_1_2.zip> is the answer
to that.

Yet another dependency - yay! With every suggestion on how to get around
deficiencies of CMake when it comes to actually build (and test)
something things are getting more complicated.

What CMake is providing here is choice and flexibility. If you want to
build on Windows with no extra tools, you can use nmake or
project/solution files. Both can be used directly from the command-line
(nmake, msbuild) with no use of a GUI, but both are a bit slow and have
no or limited parallelisation. You could use jom to speed up nmake
Makefiles. Or you can choose to generate build files for something else
entirely; personally on Windows I use Ninja due to its excellent
parallelisation and speed compared with the others. The choice is up to
the user to use an extra tool for speed, or the default tools for
convenience. I don't see this flexibility as a bad thing; it's one of
the big selling points for using CMake in the first place.


Regards,
Roger

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

[degski via Boost]

Post by Daniela Engert via Boost
Yet another dependency - yay!

Thisisi a rather big word, isn't it? Just dump the exe in a folder included
in the path and forget about it.

Post by Daniela Engert via Boost
With every suggestion on how to get around
deficiencies of CMake when it comes to actually build (and test)
something things are getting more complicated.

It's a deficiency of nmake jom is fixing, not of CMake.

Post by Daniela Engert via Boost
From my pov as a (almost
daily) tester of both individual Boost libraries and all of Boost in
different configurations, and as a Boost distro maintainer, this sounds
like a growing nightmare when I compare it to the simplicity and
ease-of-use of Boost.Build in those scenarios that I have to deal with.

Don't dis-agree with you there. Steven questioned the parallel capabilities
of nmake, and apparently it's a real concern as somebody/some peops decided
(and put the effort into it) they would offer an open source free utility
to provide the parallelisation required.

degski

[Ion Gaztañaga via Boost]

Post by degski via Boost

Post by Daniela Engert via Boost
Yet another dependency - yay!

Thisisi a rather big word, isn't it? Just dump the exe in a folder included
in the path and forget about it.

Post by Daniela Engert via Boost
With every suggestion on how to get around
deficiencies of CMake when it comes to actually build (and test)
something things are getting more complicated.

It's a deficiency of nmake jom is fixing, not of CMake.

Just to disagree, I think it's a deficiency (one of the biggest one) of
CMake because CMake, as a "build" tool, does not support parallel builds
because it depends on other build tools, including bad ones. I really
don't understand why CMake can't build things directly, it's one of its
biggest deficiencies.

One of the most important requirements of a build tool is to build
software *fast* and *portably*, without having to rely on other programs.

Best,

Ion

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

[Tim Blechmann via Boost]

Post by Ion Gaztañaga via Boost
Just to disagree, I think it's a deficiency (one of the biggest one) of
CMake because CMake, as a "build" tool, does not support parallel builds
because it depends on other build tools, including bad ones. I really
don't understand why CMake can't build things directly, it's one of its
biggest deficiencies.
One of the most important requirements of a build tool is to build
software *fast* and *portably*, without having to rely on other programs.

fwiw, systems like ninja [1] are designed to support fast and parallel
builds, the syntax is designed for that use-case, and it is designed to
be generated (by cmake or gyp).

otoh, fast compile times are not necessarily the only requirement:
parallel builds with ninja render windows unresponsive, so it are much
more suited for buildservers (macos is better, linux doesn't have this
issues). so as developer your productivity may be lower, even if the
compile times are faster.

otoh, developers who like IDEs may have a higher productivity due to
debugger integration.



[1] https://ninja-build.org/


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

[Steven Watanabe via Boost]

AMDG

Post by Tim Blechmann via Boost
parallel builds with ninja render windows unresponsive, so it are much
more suited for buildservers (macos is better, linux doesn't have this
issues). so as developer your productivity may be lower, even if the
compile times are faster.

If you want to do other things while the build is
running, then you should set the number of parallel
jobs to something less than the number of cores,
to leave some cycles free.

In Christ,
Steven Watanabe


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

[Nicolas Cornu via Boost]

Post by Steven Watanabe via Boost
If you want to do other things while the build is
running, then you should set the number of parallel
jobs to something less than the number of cores,
to leave some cycles free.

You can even tweak it with:
-l N do not start new jobs if the load average is greater than N


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

[Ion Gaztañaga via Boost]

Post by Tim Blechmann via Boost

Post by Ion Gaztañaga via Boost
Just to disagree, I think it's a deficiency (one of the biggest one) of
CMake because CMake, as a "build" tool, does not support parallel builds
because it depends on other build tools, including bad ones. I really
don't understand why CMake can't build things directly, it's one of its
biggest deficiencies.
One of the most important requirements of a build tool is to build
software *fast* and *portably*, without having to rely on other programs.

fwiw, systems like ninja [1] are designed to support fast and parallel
builds, the syntax is designed for that use-case, and it is designed to
be generated (by cmake or gyp).
parallel builds with ninja render windows unresponsive, so it are much
more suited for buildservers (macos is better, linux doesn't have this
issues). so as developer your productivity may be lower, even if the
compile times are faster.

I usually run my library tests for dozens of configurations with a
script that is launched with lower than normal priority and with -jN
with N being 1.5 times the number of CPUs (I find compiling is many
times IO-bounded). At least with a SSD disk, I can still do my low-cpu
tasks like e-mail and browsing without any problem. I'm using windows,
no idea if other OS/desktops have that problem.

I wasn't talking about a build system that freezes your computer, but
something that builds in parallel and always builds similarly in every
OS. I'm afraid that if i need to have a different "build folder" for
each configuration, project/make/ninja generation will take a
considerable time that could be used just to compile and run my tests.
Of course I don't consider any option that would force me to copy
sources (say, the boost tree) to a different sandbox to avoid
project/make/ninja generation conflicts, that would be simply crazy.

Post by Tim Blechmann via Boost
otoh, developers who like IDEs may have a higher productivity due to
debugger integration.

Sure. At least in windows you can open an executable as a project with
Visual Studio and debug it flawlessly. If there is a problem with a
Boost.Build test, I can just drop the exe into the IDE and debug it
without problems, if it has debug info (and in my local tests I activate
debug symbols also in release, just in case). For Linux gdb -tui is what
I use.

Best,

Ion

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

[paul via Boost]

Post by Tim Blechmann via Boost

Post by Ion Gaztañaga via Boost
Just to disagree, I think it's a deficiency (one of the biggest one) of
CMake because CMake, as a "build" tool, does not support parallel builds
because it depends on other build tools, including bad ones. I really
don't understand why CMake can't build things directly, it's one of its
biggest deficiencies.
One of the most important requirements of a build tool is to build
software *fast* and *portably*, without having to rely on other programs.

fwiw, systems like ninja [1] are designed to support fast and parallel
builds, the syntax is designed for that use-case, and it is designed to
be generated (by cmake or gyp).
parallel builds with ninja render windows unresponsive, so it are much
more suited for buildservers (macos is better, linux doesn't have this
issues). so as developer your productivity may be lower, even if the
compile times are faster.

I usually run my library tests for dozens of configurations with a 
script that is launched with lower than normal priority and with -jN 
with N being 1.5 times the number of CPUs (I find compiling is many 
times IO-bounded). At least with a SSD disk, I can still do my low-cpu 
tasks like e-mail and browsing without any problem. I'm using windows, 
no idea if other OS/desktops have that problem.
I wasn't talking about a build system that freezes your computer, but 
something that builds in parallel and always builds similarly in every 
OS. I'm afraid that if i need to have a different "build folder" for 
each configuration, project/make/ninja generation will take a 
considerable time that could be used just to compile and run my tests. 

The configuration is only ran once, initially, and doesn't take considerable
time.

Of course I don't consider any option that would force me to copy 
sources (say, the boost tree) to a different sandbox to avoid 
project/make/ninja generation conflicts, that would be simply crazy.

Yea, no one is talking about copying the sources. This is about multiple build
directories, but the source tree is the same.



_______________________________________________
Unsubscribe & other changes: http://lists.boos

[Tim Blechmann via Boost]

Post by Ion Gaztañaga via Boost
I usually run my library tests for dozens of configurations with a
script that is launched with lower than normal priority and with -jN
with N being 1.5 times the number of CPUs (I find compiling is many
times IO-bounded). At least with a SSD disk, I can still do my low-cpu
tasks like e-mail and browsing without any problem. I'm using windows,
no idea if other OS/desktops have that problem.

nmake, jom or ninja -jN? jom for example doesn't keep the cores as busy
as ninja in my experience. but it was just an artificial example that
there are plain build performance is not only aspect to consider ...
also some applications (sublime text and conemu for example) seem to
perform much worse under load than others

Post by Ion Gaztañaga via Boost

Post by Tim Blechmann via Boost
otoh, developers who like IDEs may have a higher productivity due to
debugger integration.

Sure. At least in windows you can open an executable as a project with
Visual Studio and debug it flawlessly. If there is a problem with a
Boost.Build test, I can just drop the exe into the IDE and debug it
without problems, if it has debug info (and in my local tests I activate
debug symbols also in release, just in case). For Linux gdb -tui is what
I use.

if you drop the exe into the ide, you can debug, but does it run the
executable with specific command line options in a specific working
directory in a specific environment? and/or does it populate a project
with source files involved and does it create a code model to allow
source navigation as in native msvc project files? debugging may be
possible, but the UX will probably differ ...

the point is not necessarily that something is possible, but that some
people prefer one workflow, but others prefer another (at least i've
learned this lesson from converting 2.5 companies with non-trivial
buildsystems to cmake).



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

[Daniela Engert via Boost]

Post by Tim Blechmann via Boost

Post by Ion Gaztañaga via Boost

Post by Tim Blechmann via Boost
otoh, developers who like IDEs may have a higher productivity due to
debugger integration.

Sure. At least in windows you can open an executable as a project with
Visual Studio and debug it flawlessly.

if you drop the exe into the ide, you can debug, but does it run the
executable with specific command line options in a specific working
directory in a specific environment?

Yes, that's totally up to you.

Post by Tim Blechmann via Boost
and/or does it populate a project
with source files involved

No it does not. It treats the binaries as kind of a project file.

Post by Tim Blechmann via Boost
and does it create a code model to allow
source navigation as in native msvc project files?

Yes, I can see no difference here.

Post by Tim Blechmann via Boost
debugging may be possible, but the UX will probably differ ...

It does: the solution explorer window is mostly empty. Besides that you
see no difference in UI and behaviour.

Ciao
Dani

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

[Tim Blechmann via Boost]

Post by Daniela Engert via Boost

Post by Tim Blechmann via Boost

Post by Ion Gaztañaga via Boost

Post by Tim Blechmann via Boost
otoh, developers who like IDEs may have a higher productivity due to
debugger integration.

Sure. At least in windows you can open an executable as a project with
Visual Studio and debug it flawlessly.

if you drop the exe into the ide, you can debug, but does it run the
executable with specific command line options in a specific working
directory in a specific environment?

Yes, that's totally up to you.

but i suppose that a user has to set this up manually as it is not
defined in the build definition

Post by Daniela Engert via Boost

Post by Tim Blechmann via Boost
and/or does it populate a project
with source files involved

No it does not. It treats the binaries as kind of a project file.

Post by Tim Blechmann via Boost
and does it create a code model to allow
source navigation as in native msvc project files?

Yes, I can see no difference here.

Post by Tim Blechmann via Boost
debugging may be possible, but the UX will probably differ ...

It does: the solution explorer window is mostly empty. Besides that you
see no difference in UI and behaviour.

... also what about xcode or clion or qtcreator? or running the
IDE-integrated static analysis tools on a codebase? or libclang based
tools that use a json compile database?


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

[Andrey Semashev via Boost]

Post by Tim Blechmann via Boost

Post by Daniela Engert via Boost

Post by Tim Blechmann via Boost

Post by Ion Gaztañaga via Boost

Post by Tim Blechmann via Boost
otoh, developers who like IDEs may have a higher productivity due to
debugger integration.

Sure. At least in windows you can open an executable as a project with
Visual Studio and debug it flawlessly.

if you drop the exe into the ide, you can debug, but does it run the
executable with specific command line options in a specific working
directory in a specific environment?

Yes, that's totally up to you.

but i suppose that a user has to set this up manually as it is not
defined in the build definition

Post by Daniela Engert via Boost

Post by Tim Blechmann via Boost
and/or does it populate a project
with source files involved

No it does not. It treats the binaries as kind of a project file.

Post by Tim Blechmann via Boost
and does it create a code model to allow
source navigation as in native msvc project files?

Yes, I can see no difference here.

Post by Tim Blechmann via Boost
debugging may be possible, but the UX will probably differ ...

It does: the solution explorer window is mostly empty. Besides that you
see no difference in UI and behaviour.

... also what about xcode or clion or qtcreator? or running the
IDE-integrated static analysis tools on a codebase? or libclang based
tools that use a json compile database?

On Linux, references to sources are typically stored in debug symbols.
So, as long as you have sources at the same location as when the
executable was built, and the debug symbols include a full path, you
should be able to view the source code. But you don't get the full code
model (with the ability to navigate the project or follow symbols)
unless you also open the project in the IDE because there is no
information about include directories or defined macros. I might be
mistaken, but the situation was similar on Windows AFAIR.

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

[Peter Dimov via Boost]

Post by degski via Boost
IMHO, the only sensible way to use CMake (from the command-line, not the
stupidly limited "IDE") with a (super-)project like boost on windows is to
generate for and use nmake.

MSBuild, rather.


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

[degski via Boost]

Post by degski via Boost
IMHO, the only sensible way to use CMake (from the command-line, not the

Post by degski via Boost
stupidly limited "IDE") with a (super-)project like boost on windows is to
generate for and use nmake.

MSBuild, rather.

But MSBuild still builds solutions and projects, no?

degski

[Peter Dimov via Boost]

Post by degski via Boost

Post by Peter Dimov via Boost

Post by degski via Boost
IMHO, the only sensible way to use CMake (from the command-line, not
the stupidly limited "IDE") with a (super-)project like boost on
windows is to generate for and use nmake.

MSBuild, rather.

But MSBuild still builds solutions and projects, no?

Who cares, you just say cmake --build . and it does its stuff. :-)


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

[degski via Boost]

Post by degski via Boost
But MSBuild still builds solutions and projects, no?
Who cares, you just say cmake --build . and it does its stuff. :-)

Could be fun to see how long it takes to open/intialize a (I'm just
putting a number, 130 libs + their tests) a 250+ projects solution (no pun
intended) with an endless number of dependencies.

degski

[David Stone via Boost]

There are many build tools you can use to build using CMake on Windows.
Ninja is one choice, but if you choose to generate VS project files, you
still have multiple options. MSBuild supports parallel builds just fine (it
was able to handle our 40 core build machine with no problems at my last
job). You can also invoke the command-line version of Visual Studio's
compiler directly, again, also with parallel builds with no problem. I
found that this was surprisingly faster than using MSBuild, but I was never
able to find out if this is true in general or just an artifact of our
build environment. In other words, there is no "extra dependency" involved
here. There are other tools that the user can choose to use as their
generator if they care (and we do not care which generator they use), but
as long as they meet the minimum requirements of having compiler installed,
you can use cmake --build to build it. Perhaps some of the confusion about
whether this can be done is parallel comes from the fact that by default,
this command will not always invoke a parallel build (it uses whatever
defaults of the generated target is, which for some systems is a single
job). For such build systems as the backend, unfortunately the user has to
invoke the command as `cmake --build -- /maxcpucount` (typing from memory),
unless this has changed in newer versions?

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

[Mike Gresens via Boost]

Post by degski via Boost
IMHO, the only sensible way to use CMake (from the command-line, not the
stupidly limited "IDE") with a (super-)project like boost on windows is to
generate for and use nmake.

Or cmake simply generates Jamfiles...

Best regards,
Mike...

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

[Tim Blechmann via Boost]

Post by degski via Boost
IMHO, the only sensible way to use CMake (from the command-line, not the
stupidly limited "IDE") with a (super-)project like boost on windows is to
generate for and use nmake.

ninja (https://ninja-build.org) works like charm on multiple platforms.

fwiw, cmake and b2 have different architecture as one is a build system
the other is a generator for build systems. both have advantages and
disadvantages.


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

[Peter Dimov via Boost]

Post by Tim Blechmann via Boost
fwiw, cmake and b2 have different architecture as one is a build system
the other is a generator for build systems.

I wonder how many of the people who repeat this mantra understand either
Boost.Build or CMake.

CMake does not generate build _systems_, it generates build _scripts_. So
does, incidentally, Boost.Build, which is a major reason why it's so hard to
understand.


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

[Rene Rivera via Boost]

On Jul 22, 2017 4:41 AM, "Peter Dimov via Boost" <***@lists.boost.org>
wrote:

Tim Blechmann wrote:

fwiw, cmake and b2 have different architecture as one is a build system the

Post by Tim Blechmann via Boost
other is a generator for build systems.

I wonder how many of the people who repeat this mantra understand either
Boost.Build or CMake.

CMake does not generate build _systems_, it generates build _scripts_. So
does, incidentally, Boost.Build, which is a major reason why it's so hard
to understand.


It would be more accurate to say that cmake generates build "scripts". And
B2 generates build "instructions" (since it's internal data structure
management).

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

[Peter Dimov via Boost]

Post by Rene Rivera via Boost

Post by Peter Dimov via Boost
CMake does not generate build _systems_, it generates build _scripts_.
So does, incidentally, Boost.Build, which is a major reason why it's so
hard to understand.

It would be more accurate to say that cmake generates build "scripts". And
B2 generates build "instructions" (since it's internal data structure
management).

You could probably make Boost.Build output a jam script with the low-level
bjam targets.

Conversely, one could probably patch CMake to generate the Ninja graph
in-memory instead of dumping it to file.


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

[Tim Blechmann via Boost]

Post by Peter Dimov via Boost

Post by Tim Blechmann via Boost
fwiw, cmake and b2 have different architecture as one is a build
system the other is a generator for build systems.

I wonder how many of the people who repeat this mantra understand either
Boost.Build or CMake.
CMake does not generate build _systems_, it generates build _scripts_.

generated project files are a bit more than *build scripts*, as
integration into IDEs like msvc, xcode or qtcreator provide a UX similar
to native project files (debuggers / profilers / static analysis etc).


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

[Andrey Semashev via Boost]

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because there
is always a possibility that Boost requires a newer CMake version that
is not available on my platform.

We could embed the required CMake distribution in boost, compile it, and
use it to build boost ?

There's the build dependencies of cmake on Ubuntu:

libarchive-dev (>= 2.8.0),
libbz2-dev,
libcurl4-openssl-dev | libcurl-ssl-dev,
libexpat1-dev,
libjsoncpp-dev,
liblzma-dev,
libncurses5-dev,
libuv1-dev,
procps [!hurd-any],
python-sphinx,
qtbase5-dev <!stage1>,
zlib1g-dev

(I've omitted the ones obviously required by Debian build scripts.)

Are you going to include those as well?

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

[Florent Castelli via Boost]

Post by Andrey Semashev via Boost

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because
there is always a possibility that Boost requires a newer CMake
version that is not available on my platform.

We could embed the required CMake distribution in boost, compile it,
and use it to build boost ?

libarchive-dev (>= 2.8.0),
libbz2-dev,
libcurl4-openssl-dev | libcurl-ssl-dev,
libexpat1-dev,
libjsoncpp-dev,
liblzma-dev,
libncurses5-dev,
libuv1-dev,
procps [!hurd-any],
python-sphinx,
qtbase5-dev <!stage1>,
zlib1g-dev
(I've omitted the ones obviously required by Debian build scripts.)
Are you going to include those as well?

All the required dependencies (beside OpenSSL for cURL) are included
with the CMake sources and it will optionally use those.
Note that some libraries are also only used for some features that are
non essential, for example libuv is only for the "server" mode of CMake
for better integration with IDEs, Qt is used for the Qt client...

Post by Andrey Semashev via Boost
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Norbert Wenzel via Boost]

Post by Florent Castelli via Boost

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because
there is always a possibility that Boost requires a newer CMake
version that is not available on my platform.

We could embed the required CMake distribution in boost, compile it,
and use it to build boost ?

There's the build dependencies of cmake on Ubuntu: [...]
Are you going to include those as well?

All the required dependencies (beside OpenSSL for cURL) are included
with the CMake sources and it will optionally use those.

We had problems with using the CMake versions of eg. cURL in our company
and switched to using the system libraries. I think this might have to
do with missing OpenSSL but cURL without TLS support is pretty useless
today. So we were not able to build our own (usable) CMake without using
system libraries.

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

[Alain Miniussi via Boost]

Post by Andrey Semashev via Boost

Post by Alain Miniussi via Boost

Post by Andrey Semashev via Boost
Actually, as a user I do care and not in favor of CMake because
there is always a possibility that Boost requires a newer CMake
version that is not available on my platform.

We could embed the required CMake distribution in boost, compile it,
and use it to build boost ?

libarchive-dev (>= 2.8.0),
libbz2-dev,
libcurl4-openssl-dev | libcurl-ssl-dev,
libexpat1-dev,
libjsoncpp-dev,
liblzma-dev,
libncurses5-dev,
libuv1-dev,
procps [!hurd-any],
python-sphinx,
qtbase5-dev <!stage1>,
zlib1g-dev
(I've omitted the ones obviously required by Debian build scripts.)
Are you going to include those as well?

I don't remember having to install anything when building cmake from
source in years (including 3.9.0 right now), either on my machines or
the ones I had no admin right. So I don't expect that to be an issue.


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

[Stefan Seefeld via Boost]

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.
Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later).

I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD. What I'm proposing can indeed be seen as one step
towards the multiplication of tools. But that would be quite a few steps
down the road, while what I'm saying here is that the step I propose
above seems to me to be essential to overcome the current stalemate. Now
assuming we progress somewhat using the above, with some libraries
having transitioned to using CMake, while others still using
Boost.Build, we have two choices: a) Test everything, and come to the
conclusion that it works well enough for users, so we can make another
release, or b) decide that we need to hold back the next release until
the remaining libraries have switched.

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
Besides, I have my doubts regarding the technical feasibility of this
heterogenous infrastructure as well. I'm sure there will be quirks and
points of incompatibiliy between the different build systems or some
seemingly unreasonable limitations that follow from this integration
that will leave someone, possibly users, unhappy.

So you think we can't transition one library at a time, but you believe
it will be possible to do a switch for 100+ libraries synchronously ?
Sorry, but I can't follow your reasoning...

I wasn't referring to the transition process but rather the resulting
model adopted by Boost. If that model includes multiple build systems
then it is bound to have problems stemming from the integration.
Regarding the transition process (to whatever build system, not
necessarilly CMake), I think both ways have its merits. Making a
whole-Boost switch is more resource expensive, but not impossible if
there are enough interested people with enough permissions to do the job.

I don't share your (apparent) mental model of software, or the practice
of software engineering. Software in general, and Boost libraries in
particular, live from the respective communities of people maintaining
and developing them. You can't just ask arbitrary "interested people"
that aren't already part of those communities to do "a job" on the
software. First, that's highly disrespectful of those who have been
working on and with the software being changed. And more importantly,
you aren't even addressing the real problem, of who would be responsible
for the maintenance of that new software ? Who would help users getting
stuck trying to build the library ? Who would fix issues ? The only
possible answer is "the community". So I think the only people who can
be reasonably expected to implement the change are actual members of
said communities. And if they aren't willing to go into the imposed
direction, there is very little you can do, if you don't want to risk a
project fork.

Post by Andrey Semashev via Boost
A step by step switch adds a period (potentially, open-ended) when
people have to maintain both build systems. As a Boost developer, I'm
not happy about that. As a user, I might not be happy either, if one
of the build systems doesn't actually work in a Boost release.

Well, if it doesn't work, don't switch ! A switch would obviously only
be useful if it improves upon the status quo.

Post by Andrey Semashev via Boost
Regarding CMake as a candidate build system, I'm not convinced that
the switch would benefit Boost in terms of "new blood" or something. I
don't think the build system is something that is keeping millions of
developers out there from contributing to Boost, as being advertised.
It might be one, though probably not the major point, but I don't
think anything will change e.g. wrt. maintenance if we switch right
now. Most of the work doesn't even touch the build system or comes
down to copying and pasting a piece of jamfile.
I recognize that CMake has gained popularity and it is easier to find
support for it online. But I know that more than once I've been
puzzled about how to do one thing or the other in it, much like with
Boost.Build. So as a Boost developer, there may be a slight plus on
CMake side for me, but absolutely not worth the damage that has been
inflicted on Boost already on the road to it. As a Boost user I really
don't care as I never ever integrate third party projects into my
project build system as I consider that a broken approach in the first
place.

Stefan

[Andrey Semashev via Boost]

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.
Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later).

I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD.

What exactly in my message is FUD?

Post by Stefan Seefeld via Boost
What I'm proposing can indeed be seen as one step
towards the multiplication of tools. But that would be quite a few steps
down the road, while what I'm saying here is that the step I propose
above seems to me to be essential to overcome the current stalemate. Now
assuming we progress somewhat using the above, with some libraries
having transitioned to using CMake, while others still using
Boost.Build, we have two choices: a) Test everything, and come to the
conclusion that it works well enough for users, so we can make another
release, or b) decide that we need to hold back the next release until
the remaining libraries have switched.

I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a release
criteria (which would be a bad idea). It would make sense to either
release half-baked support for CMake for a few Boost releases or to
follow the switch-the-whole-Boost approach: work on libraries in the
background and then merge it to develop/master for all libraries. In the
former case there's that potentially endless period of having two build
systems.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
Regarding the transition process (to whatever build system, not
necessarilly CMake), I think both ways have its merits. Making a
whole-Boost switch is more resource expensive, but not impossible if
there are enough interested people with enough permissions to do the job.

I don't share your (apparent) mental model of software, or the practice
of software engineering. Software in general, and Boost libraries in
particular, live from the respective communities of people maintaining
and developing them. You can't just ask arbitrary "interested people"
that aren't already part of those communities to do "a job" on the
software.

Sure. Those "interested people" would be members of the community.
Alternatively, these could be paid individuals acting on behalf of the
community, but I think this is unlikely to happen.

Post by Stefan Seefeld via Boost
First, that's highly disrespectful of those who have been
working on and with the software being changed. And more importantly,
you aren't even addressing the real problem, of who would be responsible
for the maintenance of that new software ? Who would help users getting
stuck trying to build the library ? Who would fix issues ?

Whatever plan you propose, nothing will happen unless all library
developers are on board. This is an obvious implied pre-requisite. Doing
it the other way will only leave you with a pile of dead code and no
maintainers.

The particular developers may not be willing or have the resource or
knowledge to do the actual transition, but it should be evident to
everyone that if and when the transition is complete (by those
interested champions willing to do the job), the maintenance burden is
left upon the particular library maintainers. This is similar to how it
happened with git and I see no other way.

There's nothing disrespectful in this approach. It would be
disrespectful if the SC or someone with universal commit permissions
imposed CMake on everyone. Which is why the latest announcement from the
SC is a big mistake, to put it mildly.

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

[Stefan Seefeld via Boost]

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.
Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later).

I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD.

What exactly in my message is FUD?

The allusion to things not going to work for Boost users, unless the
entirety of Boost has migrated to CMake. It's this claim that has taken
the actual community hostage, as it requires either a buy-in from
everyone (not going to happen), or some higher power to impose the
change (which likewise isn't going to work out in the long term, even if
it might initially look like progress).

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost
What I'm proposing can indeed be seen as one step
towards the multiplication of tools. But that would be quite a few steps
down the road, while what I'm saying here is that the step I propose
above seems to me to be essential to overcome the current stalemate. Now
assuming we progress somewhat using the above, with some libraries
having transitioned to using CMake, while others still using
Boost.Build, we have two choices: a) Test everything, and come to the
conclusion that it works well enough for users, so we can make another
release, or b) decide that we need to hold back the next release until
the remaining libraries have switched.

I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a release
criteria (which would be a bad idea). It would make sense to either
release half-baked support for CMake for a few Boost releases or to
follow the switch-the-whole-Boost approach: work on libraries in the
background and then merge it to develop/master for all libraries. In
the former case there's that potentially endless period of having two
build systems.

Not sure what you have in mind with "half-baked support for CMake".

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
Regarding the transition process (to whatever build system, not
necessarilly CMake), I think both ways have its merits. Making a
whole-Boost switch is more resource expensive, but not impossible if
there are enough interested people with enough permissions to do the job.

I don't share your (apparent) mental model of software, or the practice
of software engineering. Software in general, and Boost libraries in
particular, live from the respective communities of people maintaining
and developing them. You can't just ask arbitrary "interested people"
that aren't already part of those communities to do "a job" on the
software.

Sure. Those "interested people" would be members of the community.
Alternatively, these could be paid individuals acting on behalf of the
community, but I think this is unlikely to happen.

Indeed, because...

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost
First, that's highly disrespectful of those who have been
working on and with the software being changed. And more importantly,
you aren't even addressing the real problem, of who would be responsible
for the maintenance of that new software ? Who would help users getting
stuck trying to build the library ? Who would fix issues ?

Whatever plan you propose, nothing will happen unless all library
developers are on board. This is an obvious implied pre-requisite.
Doing it the other way will only leave you with a pile of dead code
and no maintainers.

...of this. So the only possible way forward requires the individual
communities to agree. (And I do prefer to talk about communities in
plural - it's an illusion to think of a single "boost community". There
are many, heterogeneous ones, with quite different requirements.

Post by Andrey Semashev via Boost
The particular developers may not be willing or have the resource or
knowledge to do the actual transition, but it should be evident to
everyone that if and when the transition is complete (by those
interested champions willing to do the job), the maintenance burden is
left upon the particular library maintainers. This is similar to how
it happened with git and I see no other way.

Don't force anyone !

Post by Andrey Semashev via Boost
There's nothing disrespectful in this approach. It would be
disrespectful if the SC or someone with universal commit permissions
imposed CMake on everyone. Which is why the latest announcement from
the SC is a big mistake, to put it mildly.

Oh, so we actually agree - or almost. :-)
It seems the main difference is that you think the burden is the
required work to switch, while to me it's the maintenance work after the
switch.

Stefan

[Andrey Semashev via Boost]

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD.

What exactly in my message is FUD?

The allusion to things not going to work for Boost users, unless the
entirety of Boost has migrated to CMake.

This is not what I was saying. I was saying that the model of each
library using its own build system won't work well for users.

Post by Stefan Seefeld via Boost
It's this claim that has taken
the actual community hostage, as it requires either a buy-in from
everyone (not going to happen),

If people don't agree to switch then the transition is not going to
happen. Either that or those people will follow Rene's example.

Post by Stefan Seefeld via Boost
or some higher power to impose the
change (which likewise isn't going to work out in the long term, even if
it might initially look like progress).

Right.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a release
criteria (which would be a bad idea). It would make sense to either
release half-baked support for CMake for a few Boost releases or to
follow the switch-the-whole-Boost approach: work on libraries in the
background and then merge it to develop/master for all libraries. In
the former case there's that potentially endless period of having two
build systems.

Not sure what you have in mind with "half-baked support for CMake".

It means with CMake transition unfinished. Not all libraries converted,
non-functional build/test/docs with CMake, etc.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
The particular developers may not be willing or have the resource or
knowledge to do the actual transition, but it should be evident to
everyone that if and when the transition is complete (by those
interested champions willing to do the job), the maintenance burden is
left upon the particular library maintainers. This is similar to how
it happened with git and I see no other way.

Don't force anyone !

Not sure what you mean. Noone's forcing anyone. Well, except the SC
after the announcement.

I'll paraphrase my point, in case if I failed to communicate. Basically,
a Boost maintainer has the following options:

0. Actively help the transition and maintenance of CMake afterwards.

1. Accept the burden of maintaining CMake for his library. Depending on
the migration plan and the final model, CMake may be the only build
system to maintain or be an addition to Boost.Build.

2. Resign from maintenance.

3. Actively object migrating their particular library, leaving Boost
multi-build-system.

4. Despite the SC the community decides not to switch to CMake and
everything is kept as is.

Everyone are free to pick their poison.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
There's nothing disrespectful in this approach. It would be
disrespectful if the SC or someone with universal commit permissions
imposed CMake on everyone. Which is why the latest announcement from
the SC is a big mistake, to put it mildly.

Oh, so we actually agree - or almost. :-)
It seems the main difference is that you think the burden is the
required work to switch, while to me it's the maintenance work after the
switch.

Both are, and both require volunteers.

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

[Stefan Seefeld via Boost]

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD.

What exactly in my message is FUD?

The allusion to things not going to work for Boost users, unless the
entirety of Boost has migrated to CMake.

This is not what I was saying. I was saying that the model of each
library using its own build system won't work well for users.

But in this thread I'm not proposing each library to use "its own build
system". I'm proposing to allow each library to choose whether to move
to CMake or to stay with Boost.Build, as an attempt to unlock the
current gridlock.

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost
It's this claim that has taken
the actual community hostage, as it requires either a buy-in from
everyone (not going to happen),

If people don't agree to switch then the transition is not going to
happen. Either that or those people will follow Rene's example.

That's the problem. Some people are frustrated if they have to move,
other are frustrated if they have to stay. Thus an "either or" scenario
can't be the answer.

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost
or some higher power to impose the
change (which likewise isn't going to work out in the long term, even if
it might initially look like progress).

Right.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a release
criteria (which would be a bad idea). It would make sense to either
release half-baked support for CMake for a few Boost releases or to
follow the switch-the-whole-Boost approach: work on libraries in the
background and then merge it to develop/master for all libraries. In
the former case there's that potentially endless period of having two
build systems.

Not sure what you have in mind with "half-baked support for CMake".

It means with CMake transition unfinished. Not all libraries
converted, non-functional build/test/docs with CMake, etc.

But if some projects complete the transition, there isn't anything
"unfinished", at least not if the infrastructure is set up to support
this. It's what's called incremental progress. To paraphrase: it's
better to have x% of the libraries converted 100% than 100% of the
libraries converted x%.

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
The particular developers may not be willing or have the resource or
knowledge to do the actual transition, but it should be evident to
everyone that if and when the transition is complete (by those
interested champions willing to do the job), the maintenance burden is
left upon the particular library maintainers. This is similar to how
it happened with git and I see no other way.

Don't force anyone !

Not sure what you mean. Noone's forcing anyone. Well, except the SC
after the announcement.

Huh, now it's me who isn't sure what you mean :-) Can you please
rephrase this last set of sentences ? I'm not sure what you are trying
to say here. :-)

Post by Andrey Semashev via Boost
I'll paraphrase my point, in case if I failed to communicate.
0. Actively help the transition and maintenance of CMake afterwards.
1. Accept the burden of maintaining CMake for his library. Depending
on the migration plan and the final model, CMake may be the only build
system to maintain or be an addition to Boost.Build.
2. Resign from maintenance.
3. Actively object migrating their particular library, leaving Boost
multi-build-system.
4. Despite the SC the community decides not to switch to CMake and
everything is kept as is.
Everyone are free to pick their poison.

Again, not sure what your point is in listing these options. To me it
seems clear that the SC is asking us to pick between 0. and 1., while I
propose 3.

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
There's nothing disrespectful in this approach. It would be
disrespectful if the SC or someone with universal commit permissions
imposed CMake on everyone. Which is why the latest announcement from
the SC is a big mistake, to put it mildly.

Oh, so we actually agree - or almost. :-)
It seems the main difference is that you think the burden is the
required work to switch, while to me it's the maintenance work after the
switch.

Both are, and both require volunteers.

So ?

Stefan

[Andrey Semashev via Boost]

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD.

What exactly in my message is FUD?

The allusion to things not going to work for Boost users, unless the
entirety of Boost has migrated to CMake.

This is not what I was saying. I was saying that the model of each
library using its own build system won't work well for users.

But in this thread I'm not proposing each library to use "its own build
system". I'm proposing to allow each library to choose whether to move
to CMake or to stay with Boost.Build, as an attempt to unlock the
current gridlock.

Right. For users, that would be somewhat better than everyone using
their own build system, but the problems that I described in my original
reply in this thread remain.

Again, I think for many users half CMake-based half Boost.Build-based
Boost distribution would be more difficult to use than just CMake-based
or just Boost.Build-based distribution.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
The particular developers may not be willing or have the resource or
knowledge to do the actual transition, but it should be evident to
everyone that if and when the transition is complete (by those
interested champions willing to do the job), the maintenance burden is
left upon the particular library maintainers. This is similar to how
it happened with git and I see no other way.

Don't force anyone !

Not sure what you mean. Noone's forcing anyone. Well, except the SC
after the announcement.

Huh, now it's me who isn't sure what you mean :-) Can you please
rephrase this last set of sentences ? I'm not sure what you are trying
to say here. :-)

I was coming from the premise of Boost migrating to CMake as a whole,
which is what I think is being suggested by the SC. In this scenario,
each maintainer has the options I listed below.

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
0. Actively help the transition and maintenance of CMake afterwards.
1. Accept the burden of maintaining CMake for his library. Depending
on the migration plan and the final model, CMake may be the only build
system to maintain or be an addition to Boost.Build.
2. Resign from maintenance.
3. Actively object migrating their particular library, leaving Boost
multi-build-system.
4. Despite the SC the community decides not to switch to CMake and
everything is kept as is.
Everyone are free to pick their poison.

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

[Florent Castelli via Boost]

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
I'm sure it's been mentioned before by someone, but as a Boost user
and packager (for my work projects) I don't want to deal with a dozen
of build systems (worse yet - multiple versions of the same build
system) to be able to build Boost. Having a single build system, a
single interface and customization point is an important advantage
regardless of what the actual build system is used.

Don't you realize how impossible this has become, given the current size
and scale of Boost ? You can't treat a project like Boost, with > 100
individual libraries in it, as a single entity. It's not going to work.
And each attempt to impose a change will result in endless discussions
leading nowhere. We have to face this reality, and break Boost up into
parts that individually are amenable to such change. But not as a single
orchestrated switch.
Also, please note that I did not suggest that we open the door for any
other build systems (though that certainly could become an interesting
discussion later).

I think you did advocate for the model where each library picks its
own tools, including the build system. Allowing two build systems
would be just the first step. I'm just saying that this won't work
well for Boost users, at least not for a significant part of them.

That's just FUD.

What exactly in my message is FUD?

Post by Stefan Seefeld via Boost
What I'm proposing can indeed be seen as one step
towards the multiplication of tools. But that would be quite a few steps
down the road, while what I'm saying here is that the step I propose
above seems to me to be essential to overcome the current stalemate. Now
assuming we progress somewhat using the above, with some libraries
having transitioned to using CMake, while others still using
Boost.Build, we have two choices: a) Test everything, and come to the
conclusion that it works well enough for users, so we can make another
release, or b) decide that we need to hold back the next release until
the remaining libraries have switched.

I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a release
criteria (which would be a bad idea). It would make sense to either
release half-baked support for CMake for a few Boost releases or to
follow the switch-the-whole-Boost approach: work on libraries in the
background and then merge it to develop/master for all libraries. In
the former case there's that potentially endless period of having two
build systems.

You could possibly ask developers from other major project who
transitioned to CMake what was their experience. LLVM moved exclusively
to CMake not too long ago and it would certainly be interesting for
people doubting it is possible to talk to their build engineers and
developers.
Note that some people (certainly not everyone) are quite happy with the
transition, I saw again some message the other day from people loving
the new changes in the latest CMake and it made LLVM compile much faster.

Post by Andrey Semashev via Boost

Post by Stefan Seefeld via Boost

Post by Andrey Semashev via Boost
Regarding the transition process (to whatever build system, not
necessarilly CMake), I think both ways have its merits. Making a
whole-Boost switch is more resource expensive, but not impossible if
there are enough interested people with enough permissions to do the job.

I don't share your (apparent) mental model of software, or the practice
of software engineering. Software in general, and Boost libraries in
particular, live from the respective communities of people maintaining
and developing them. You can't just ask arbitrary "interested people"
that aren't already part of those communities to do "a job" on the
software.

Sure. Those "interested people" would be members of the community.
Alternatively, these could be paid individuals acting on behalf of the
community, but I think this is unlikely to happen.

Post by Stefan Seefeld via Boost
First, that's highly disrespectful of those who have been
working on and with the software being changed. And more importantly,
you aren't even addressing the real problem, of who would be responsible
for the maintenance of that new software ? Who would help users getting
stuck trying to build the library ? Who would fix issues ?

Whatever plan you propose, nothing will happen unless all library
developers are on board. This is an obvious implied pre-requisite.
Doing it the other way will only leave you with a pile of dead code
and no maintainers.
The particular developers may not be willing or have the resource or
knowledge to do the actual transition, but it should be evident to
everyone that if and when the transition is complete (by those
interested champions willing to do the job), the maintenance burden is
left upon the particular library maintainers. This is similar to how
it happened with git and I see no other way.

I'm certain there will be build engineers like myself and many others
willing to send PR to transition libraries to CMake once a design has
been chosen. Then it's up to the library owners to merge them in due time.

Post by Andrey Semashev via Boost
There's nothing disrespectful in this approach. It would be
disrespectful if the SC or someone with universal commit permissions
imposed CMake on everyone. Which is why the latest announcement from
the SC is a big mistake, to put it mildly.
_______________________________________________
http://lists.boost.org/mailman/listinfo.cgi/boost

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

[Stefan Seefeld via Boost]

Post by Florent Castelli via Boost

Post by Andrey Semashev via Boost
I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a
release criteria (which would be a bad idea). It would make sense to
either release half-baked support for CMake for a few Boost releases
or to follow the switch-the-whole-Boost approach: work on libraries
in the background and then merge it to develop/master for all
libraries. In the former case there's that potentially endless period
of having two build systems.

You could possibly ask developers from other major project who
transitioned to CMake what was their experience. LLVM moved
exclusively to CMake not too long ago and it would certainly be
interesting for people doubting it is possible to talk to their build
engineers and developers.
Note that some people (certainly not everyone) are quite happy with
the transition, I saw again some message the other day from people
loving the new changes in the latest CMake and it made LLVM compile
much faster.

All this is beside the point, as we are not arguing about the respective
advantages or disadvantages in Boost.Build or CMake. The point is about
who has the burden to a) implement the change and b) to maintain the
infrastructure, and how that affects (or should affect) the decision
making process.

Stefan

[Florent Castelli via Boost]

Post by Stefan Seefeld via Boost

Post by Florent Castelli via Boost

Post by Andrey Semashev via Boost
I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a
release criteria (which would be a bad idea). It would make sense to
either release half-baked support for CMake for a few Boost releases
or to follow the switch-the-whole-Boost approach: work on libraries
in the background and then merge it to develop/master for all
libraries. In the former case there's that potentially endless period
of having two build systems.

You could possibly ask developers from other major project who
transitioned to CMake what was their experience. LLVM moved
exclusively to CMake not too long ago and it would certainly be
interesting for people doubting it is possible to talk to their build
engineers and developers.
Note that some people (certainly not everyone) are quite happy with
the transition, I saw again some message the other day from people
loving the new changes in the latest CMake and it made LLVM compile
much faster.

All this is beside the point, as we are not arguing about the respective
advantages or disadvantages in Boost.Build or CMake. The point is about
who has the burden to a) implement the change and b) to maintain the
infrastructure, and how that affects (or should affect) the decision
making process.

No this is directly commenting on this point. LLVM did a gradual
transition, they survived and are moving forward.
If someone questions the possibility of doing the same, then they can
just ask them how they did it.
Remember they probably have way more developers working on it than Boost
itself and a successful migration.

Post by Stefan Seefeld via Boost
Stefan

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

[Andrey Semashev via Boost]

Post by Florent Castelli via Boost

Post by Stefan Seefeld via Boost

Post by Florent Castelli via Boost

Post by Andrey Semashev via Boost
I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a
release criteria (which would be a bad idea). It would make sense to
either release half-baked support for CMake for a few Boost releases
or to follow the switch-the-whole-Boost approach: work on libraries
in the background and then merge it to develop/master for all
libraries. In the former case there's that potentially endless period
of having two build systems.

You could possibly ask developers from other major project who
transitioned to CMake what was their experience. LLVM moved
exclusively to CMake not too long ago and it would certainly be
interesting for people doubting it is possible to talk to their build
engineers and developers.
Note that some people (certainly not everyone) are quite happy with
the transition, I saw again some message the other day from people
loving the new changes in the latest CMake and it made LLVM compile
much faster.

All this is beside the point, as we are not arguing about the respective
advantages or disadvantages in Boost.Build or CMake. The point is about
who has the burden to a) implement the change and b) to maintain the
infrastructure, and how that affects (or should affect) the decision
making process.

No this is directly commenting on this point. LLVM did a gradual
transition, they survived and are moving forward.
If someone questions the possibility of doing the same, then they can
just ask them how they did it.
Remember they probably have way more developers working on it than Boost
itself and a successful migration.

I don't question that the transition can be done in principle. I don't
think it can be done in the time span of one Boost release, which is
about 4 months.

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

[Andrey Semashev via Boost]

Post by Florent Castelli via Boost

Post by Andrey Semashev via Boost
I don't think it is realistic to convert the whole Boost in a single
release time frame, unless you want to put the transition as a release
criteria (which would be a bad idea). It would make sense to either
release half-baked support for CMake for a few Boost releases or to
follow the switch-the-whole-Boost approach: work on libraries in the
background and then merge it to develop/master for all libraries. In
the former case there's that potentially endless period of having two
build systems.

You could possibly ask developers from other major project who
transitioned to CMake what was their experience. LLVM moved exclusively
to CMake not too long ago and it would certainly be interesting for
people doubting it is possible to talk to their build engineers and
developers.
Note that some people (certainly not everyone) are quite happy with the
transition, I saw again some message the other day from people loving
the new changes in the latest CMake and it made LLVM compile much faster.

I don't follow LLVM development and not familiar with their specifics,
but I suspect their organization is different from Boost. Do they have
100+ more or less independent libraries, each having its maintainers and
preferences, with no central government?

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

[Robert Ramey via Boost]

Post by Stefan Seefeld via Boost

Post by Thomas Heller via Boost
Hi list,
After there has been a heated debated over the last three days over the
switch to CMake, I'd like to share my observations...
First of all, a general observation: In this discussion, there generally
seems to two camps: Those who know Boost.Build and those who know CMake.

Mostly, yes. And in addition, people are very polarized (even more so as
a result of this ongoing discussion). So to frame the question as
"should we stay with Boost.Build or should we move to CMake" is
extremely counter-productive.
We need a way to continue to draw from the wealth of expertise encoded
in the existing Boost.Build infrastructure as well as the community
around it, while at the same time being open to change (in general, not
just towards alternative build tools). To invoke a higher authority to
decide to get out of this stalemate is foolish, as it entirely ignores
both how Open Source works in general (you can't coerce people into
doing things they aren't motivated to do to begin with), as well as the
either Boost.Build or CMake, globally, for everyone at once.
* Improve the existing Boost.Build infrastructure to allow libraries to
be built stand-alone. (I remember from discussing with Rene a year ago
that he had some work in progress to achieve this, so I don't think this
is particularly hard, at least not for someone understanding Boost.Build
internals).

This is already in place. I all the time. Here is what I do:
a) I make a change to some library
b) I cd to the test directory of the library
c) I invoke b2 to build and run the tests (I do this through the
library_test macro in boost/tools, but that's not essential).
d) the b2 build any dependent libraries and runs the tests of the
library I'm working on.

Post by Stefan Seefeld via Boost
* Replace the top-level build logic to simply iterate over all
libraries, invoking this stand-alone build logic.

This is what the top level build logic does. I once posted a simple
shell script which would do exactly that. I turned out that this didn't
work because the top level system had some library specific logic in it
to accomodate some libraries which "do their own thing". I noted at the
time that it was a mistake to do this and that library authors should
have committed to boost requirements rather than the other way around.

Post by Stefan Seefeld via Boost
* With the above in place, it becomes possible to switch from
Boost.Build to CMake one library at a time, so the original question can
be reframed as "which library wants to switch from Boost.Build to
CMake", which, I'm sure, will be much less disruptive (if at all) and
non-controversial, as the people to decide will be project maintainers
and communities.

This is indeed possible. In fact its quite easy. I created CMake
CMakeList.txt files for the serialization libary - which has a very
complex testing regimen. It's also not header only and supports a lot
of variants, static, debug, the works. The safe numerics version even
supports the CDash functionality which would be very useful to boost. I
didn't like the way CMake implemented though. I did this because I
wanted to be able to create an IDE for editing, testing and debugging
the library.

It's very easy for anyone who is interested to invoke CMake in the
serialization directory, build and IDE and open it up and see what you
get. So far as I know - only one person has actually done this.

Post by Stefan Seefeld via Boost
Does this process appeal to anyone ?

Makes total sense to me.

There are a couple of I haven't addressed because I haven't need them.

a) The CDash functionality - needs a much better solution
c) The CPack - packager - I have never figured out the utility of this
c) FindBoostSerialization library. THis might be interesting to users
or maybe not. When I use Boost in a CMake project I use FindBoost.
This doesn't really work, but with some horsing around it can be made to
work.

There are lots of opinions on this thread amounting to saying "Here is
what needs to be done - Developers (or someone else) should be forced to
do it". This has gone nowhere and is not going anywhere. The SC can
make any pronouncement it wants, but that's all its going to be until
someone actually DOES something. The closed I've seen are my pages on
CMake in the incubator and Peter Dimovs CMake proposal (which I haven't
had time to study). Other than that ... nothing of substance.

Robert Ramey

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

[Ion Gaztañaga via Boost]

Post by Thomas Heller via Boost
Hi list,
After there has been a heated debated over the last three days over the
switch to CMake, I'd like to share my observations...

Thomas, I absolutely agree. Let's make users life easier first, even for
those not using CMake.

Best,

Ion

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