Switch to CMake -- Analysis

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
82 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Switch to CMake -- Analysis

Boost - Dev mailing list
Hi list,

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

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

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

Now, on to the motivation for switching, as presented in the announcement:
On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
> [...] our build system has become an impediment for many developers
> and users, existing and prospective.

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

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

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

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

Regards,
Thomas

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:

> Hi list,
>
> After there has been a heated debated over the last three days over the
> switch to CMake, I'd like to share my observations...
>
> First of all, a general observation: In this discussion, there generally
> seems to two camps: Those who know Boost.Build and those who know CMake.
> Unfortunately, there doesn't seem to be any overlap between those
> groups, which generally made the discussions about a potential switch to
> CMake unfruitful, often leading to misunderstandings due to a lack of
> knowledge about the other tool. There is no doubt, that the group of
> people knowing CMake is larger and that projects using CMake far
> outnumber the ones using Boost.Build. A thousand flies can't be wrong,
> right? Is the popularity of CMake really the only benefit?
>
> Here is the thing, from my point of view: Apart from the different
> philosophy (Build System vs. Build System generator), in the end, you
> get a executable/library out of the system. From a pragmatic point of
> view, the only thing that changes to develop/build/test/use a library is
> the work flow. Leaving aside the disruptive and its effects of such.
>
> Now, on to the motivation for switching, as presented in the announcement:
> On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:
> >
> > [...] our build system has become an impediment for many developers
> > and users, existing and prospective.
> Let's look at users first. Yes, FindBoost.cmake has its problems, but it
> works in 90% of the cases (from my own experience). This can, and should
> certainly be improved. Providing the necessary XXX-config.cmake files is
> what fixes this. There has been movement in that direction, with code,
> which could be just improved upon. This will fix those cases. The other
> group of library consumers, expressed the urge to build boost directly
> as part of their build process. That hasn't been done yet, but I am
> pretty certain, there are no road blocks to actually write such a CMake
> Module, which invokes b2 instead of the compiler directly inside of the
> superproject. Together with the generated XXX-config.cmake files, this
> use case is covered. From my recollection of the various discussions,
> this approach was not contentious at all, it wouldn't even require
> interaction with all library maintainers, and all CMake users (existing
> or prospective) would immediately benefit.
>
> Now on to developers. There is obviously a lot of resistance from
> existing developers (for various reasons, which are not really relevant
> for the discussion at hand). In my opinion, maintaining two build
> systems is a no-go. Either make a clear cut, or don't. Please don't
> waste resources on maintaining and supporting both. With this line of
> thought as the background, this will create massive disruption.
> Switching the whole of boost (including infrastructure, documentation
> etc.) to be built and tested with CMake is not easy and take a lot of
> time, leaving a void for both maintainers and prospective boost library
> authors.
>
> Now, the argument that has been brought up very often in favor for the
> switch is that it will attract more contributors, but will it really?
> I am reluctant to the idea that people don't contribute new libraries to
> boost just because of the build system. Despite a switch to cmake, you'd
> still have to conform to Boost.CMake guidelines and somehow make your
> library buildable and testable within and outside of the Boost Tree
> (there might be a straight forward solution to this).
> Furthermore, I often hear something like "in the presence of GitHub and
> CMake people don't think about submitting to boost anymore". This is
> exactly the point. But it has nothing to do with the "and CMake" suffix.
> It's is just far more easier and convenient to drop you library to
> GitHub, advertise it on various channels and call it a day. I hear you
> say: "Sure, but libraries will only be adopted if they come with CMake."
> That might very well be true, but what has this to do with Boost?
> Compare the lengthy and exhausting review process you have to go through
> with the click of a few buttons and hammering something onto a keyboard.
> And no, Robert, while the incubator was a nice idea, it doesn't
> compensate that either ;)
>
> All in all, I am pretty confident that a disruptive switch will hurt
> Boost more than it brings benefit. This already happened. To come to an
> end and summarize: Provide proper CMake integration, such that Boost is
> consumable by those (while you are at it, don't forget meson, bazel and
> pkg-config).

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
Am 21.07.2017 4:55 nachm. schrieb "paul" <[hidden email]>:

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

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Thomas
> Heller via Boost
> Sent: Freitag, 21. Juli 2017 16:21
> To: [hidden email]
> Cc: Thomas Heller <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 07/21/17 18:00, Thomas Heller via Boost wrote:

> Am 21.07.2017 4:55 nachm. schrieb "paul" <[hidden email]>:
>
> On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
>>
>> All in all, I am pretty confident that a disruptive switch will hurt
>> Boost more than it brings benefit. This already happened. To come to an
>> end and summarize: Provide proper CMake integration, such that Boost is
>> consumable by those (while you are at it, don't forget meson, bazel and
>> pkg-config).
>
> pkg-config is build-indenpendent so can be consumed by meson and bazel.
>
> It's also consumable by cmake. Doesn't propagate build properties though.
> Only plain and simple strings on how to invoke the compiler/linker.
> Anything else is not the default behavior.

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" <
[hidden email]>:

On 07/21/17 18:00, Thomas Heller via Boost wrote:

> Am 21.07.2017 4:55 nachm. schrieb "paul" <[hidden email]>:
>
> On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
>
>>
>> All in all, I am pretty confident that a disruptive switch will hurt
>> Boost more than it brings benefit. This already happened. To come to an
>> end and summarize: Provide proper CMake integration, such that Boost is
>> consumable by those (while you are at it, don't forget meson, bazel and
>> pkg-config).
>>
>
> pkg-config is build-indenpendent so can be consumed by meson and bazel.
>
> It's also consumable by cmake. Doesn't propagate build properties though.
> Only plain and simple strings on how to invoke the compiler/linker.
> Anything else is not the default behavior.
>

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


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



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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 21.07.2017 5:15 nachm. schrieb "Groke, Paul via Boost" <
[hidden email]>:

> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Thomas
> Heller via Boost
> Sent: Freitag, 21. Juli 2017 16:21
> To: [hidden email]
> Cc: Thomas Heller <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

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

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

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

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

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


Does this process appeal to anyone ?

Regards,
        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost
<[hidden email]> wrote:
> Does this process appeal to anyone ?

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

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

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

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

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
On 21.07.2017 12:03, Vinnie Falco via Boost wrote:
> On Fri, Jul 21, 2017 at 8:57 AM, Stefan Seefeld via Boost
> <[hidden email]> wrote:
>> Does this process appeal to anyone ?
> It sounds reasonable in theory, but I think the first thing that
> should be addressed is the use-case where Users of Boost who have
> pre-built binaries are able to easily consume Boost in their projects
> with support from within Boost itself and not the FindBoost.cmake that
> comes with CMake which is perpetually behind the latest Boost version.

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

        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 07/21/17 18:57, Stefan Seefeld via Boost wrote:

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

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jul 21, 2017 at 9:15 AM, Stefan Seefeld via Boost
<[hidden email]> wrote:
> You are talking about a use-case involving a Boost *binary* package. How
> is this related to how Boost is built, i.e. how such binaries are
> produced ?

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 21.07.2017 12:16, Andrey Semashev via Boost wrote:

> On 07/21/17 18:57, Stefan Seefeld via Boost wrote:
>>
>> Here is (once again) how I would approach this instead:
>>
>> * Improve the existing Boost.Build infrastructure to allow libraries to
>> be built stand-alone. (I remember from discussing with Rene a year ago
>> that he had some work in progress to achieve this, so I don't think this
>> is particularly hard, at least not for someone understanding Boost.Build
>> internals).
>> * Replace the top-level build logic  to simply iterate over all
>> libraries, invoking this stand-alone build logic.
>> * With the above in place, it becomes possible to switch from
>> Boost.Build to CMake one library at a time, so the original question can
>> be reframed as "which library wants to switch from Boost.Build to
>> CMake", which, I'm sure, will be much less disruptive (if at all) and
>> non-controversial, as the people to decide will be project maintainers
>> and communities.
>>
>> Does this process appeal to anyone ?
>
> I'm sure it's been mentioned before by someone, but as a Boost user
> and packager (for my work projects) I don't want to deal with a dozen
> of build systems (worse yet - multiple versions of the same build
> system) to be able to build Boost. Having a single build system, a
> single interface and customization point is an important advantage
> regardless of what the actual build system is used.

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

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


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

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

        Stefan




--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 21.07.2017 12:19, Vinnie Falco via Boost wrote:
> On Fri, Jul 21, 2017 at 9:15 AM, Stefan Seefeld via Boost
> <[hidden email]> wrote:
>> You are talking about a use-case involving a Boost *binary* package. How
>> is this related to how Boost is built, i.e. how such binaries are
>> produced ?
> It is not related to building Boost but it solves something that
> annoys a non-zero percentage of Boost users who use CMake.

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

        Stefan


--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost
<[hidden email]> wrote:
> Then *please* let's not add unrelated points to the discussion, for the
> sake of getting a handle of what problems we have to solve, and how.

Hmm...my apologies but I think this error is very much on-topic:

>CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message):
>Imported targets not available for Boost version

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 2017-07-21 at 17:39 +0200, Thomas Heller via Boost wrote:

> Am 21.07.2017 5:18 nachm. schrieb "Andrey Semashev via Boost" <
> [hidden email]>:
>
> On 07/21/17 18:00, Thomas Heller via Boost wrote:
>
> >
> > Am 21.07.2017 4:55 nachm. schrieb "paul" <[hidden email]>:
> >
> > On Fri, 2017-07-21 at 16:21 +0200, Thomas Heller via Boost wrote:
> >
> > >
> > >
> > > All in all, I am pretty confident that a disruptive switch will hurt
> > > Boost more than it brings benefit. This already happened. To come to an
> > > end and summarize: Provide proper CMake integration, such that Boost is
> > > consumable by those (while you are at it, don't forget meson, bazel and
> > > pkg-config).
> > >
> > pkg-config is build-indenpendent so can be consumed by meson and bazel.
> >
> > It's also consumable by cmake. Doesn't propagate build properties though.
> > Only plain and simple strings on how to invoke the compiler/linker.
> > Anything else is not the default behavior.
> >
> It does, at least with regard to macros to define, include/library
> directories to add and libraries to link with. Or do you have different
> properties in mind?
>
>
> Well, recently, cmake got support for c++ feature properties for example.
> The big advantage is that the flags carry on semantics and the build system
> is able to determine conflicts etc.

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 07/21/17 19:30, Stefan Seefeld via Boost wrote:

> On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
>>
>> I'm sure it's been mentioned before by someone, but as a Boost user
>> and packager (for my work projects) I don't want to deal with a dozen
>> of build systems (worse yet - multiple versions of the same build
>> system) to be able to build Boost. Having a single build system, a
>> single interface and customization point is an important advantage
>> regardless of what the actual build system is used.
>
> Don't you realize how impossible this has become, given the current size
> and scale of Boost ? You can't treat a project like Boost, with > 100
> individual libraries in it, as a single entity. It's not going to work.
> And each attempt to impose a change will result in endless discussions
> leading nowhere. We have to face this reality, and break Boost up into
> parts that individually are amenable to such change. But not as a single
> orchestrated switch.
>
> Also, please note that I did not suggest that we open the door for any
> other build systems (though that certainly could become an interesting
> discussion later).

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

>> Besides, I have my doubts regarding the technical feasibility of this
>> heterogenous infrastructure as well. I'm sure there will be quirks and
>> points of incompatibiliy between the different build systems or some
>> seemingly unreasonable limitations that follow from this integration
>> that will leave someone, possibly users, unhappy.
>
> So you think we can't transition one library at a time, but you believe
> it will be possible to do a switch for 100+ libraries synchronously ?
> Sorry, but I can't follow your reasoning...

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

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

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 21.07.2017 6:42 nachm. schrieb "Vinnie Falco via Boost" <
[hidden email]>:

On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost
<[hidden email]> wrote:
> Then *please* let's not add unrelated points to the discussion, for the
> sake of getting a handle of what problems we have to solve, and how.

Hmm...my apologies but I think this error is very much on-topic:

>CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762
(message):
>Imported targets not available for Boost version



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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 7/21/17 8:57 AM, Stefan Seefeld via Boost wrote:

> On 21.07.2017 10:21, Thomas Heller via Boost wrote:
>> Hi list,
>>
>> After there has been a heated debated over the last three days over the
>> switch to CMake, I'd like to share my observations...
>>
>> First of all, a general observation: In this discussion, there generally
>> seems to two camps: Those who know Boost.Build and those who know CMake.
>
> Mostly, yes. And in addition, people are very polarized (even more so as
> a result of this ongoing discussion). So to frame the question as
> "should we stay with Boost.Build or should we move to CMake" is
> extremely counter-productive.
>
> We need a way to continue to draw from the wealth of expertise encoded
> in the existing Boost.Build infrastructure as well as the community
> around it, while at the same time being open to change (in general, not
> just towards alternative build tools). To invoke a higher authority to
> decide to get out of this stalemate is foolish, as it entirely ignores
> both how Open Source works in general (you can't coerce people into
> doing things they aren't motivated to do to begin with), as well as the
> real reason for the stalemate: it's due to an artificial dichotomy:
> either Boost.Build or CMake, globally, for everyone at once.
>
> Here is (once again) how I would approach this instead:
>
> * Improve the existing Boost.Build infrastructure to allow libraries to
> be built stand-alone. (I remember from discussing with Rene a year ago
> that he had some work in progress to achieve this, so I don't think this
> is particularly hard, at least not for someone understanding Boost.Build
> internals).

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

> * Replace the top-level build logic  to simply iterate over all
> libraries, invoking this stand-alone build logic.

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

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

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

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

> Does this process appeal to anyone ?

Makes total sense to me.

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

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

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

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Switch to CMake -- Analysis

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 07/21/17 20:10, Andrey Semashev wrote:

> On 07/21/17 19:30, Stefan Seefeld via Boost wrote:
>> On 21.07.2017 12:16, Andrey Semashev via Boost wrote:
>>>
>>> I'm sure it's been mentioned before by someone, but as a Boost user
>>> and packager (for my work projects) I don't want to deal with a dozen
>>> of build systems (worse yet - multiple versions of the same build
>>> system) to be able to build Boost. Having a single build system, a
>>> single interface and customization point is an important advantage
>>> regardless of what the actual build system is used.
>>
>> Don't you realize how impossible this has become, given the current size
>> and scale of Boost ? You can't treat a project like Boost, with > 100
>> individual libraries in it, as a single entity. It's not going to work.
>> And each attempt to impose a change will result in endless discussions
>> leading nowhere. We have to face this reality, and break Boost up into
>> parts that individually are amenable to such change. But not as a single
>> orchestrated switch.
>>
>> Also, please note that I did not suggest that we open the door for any
>> other build systems (though that certainly could become an interesting
>> discussion later).
>
> I think you did advocate for the model where each library picks its own
> tools, including the build system. Allowing two build systems would be
> just the first step. I'm just saying that this won't work well for Boost
> users, at least not for a significant part of them.
>
>>> Besides, I have my doubts regarding the technical feasibility of this
>>> heterogenous infrastructure as well. I'm sure there will be quirks and
>>> points of incompatibiliy between the different build systems or some
>>> seemingly unreasonable limitations that follow from this integration
>>> that will leave someone, possibly users, unhappy.
>>
>> So you think we can't transition one library at a time, but you believe
>> it will be possible to do a switch for 100+ libraries synchronously ?
>> Sorry, but I can't follow your reasoning...
>
> I wasn't referring to the transition process but rather the resulting
> model adopted by Boost. If that model includes multiple build systems
> then it is bound to have problems stemming from the integration.
>
> Regarding the transition process (to whatever build system, not
> necessarilly CMake), I think both ways have its merits. Making a
> whole-Boost switch is more resource expensive, but not impossible if
> there are enough interested people with enough permissions to do the
> job. A step by step switch adds a period (potentially, open-ended) when
> people have to maintain both build systems. As a Boost developer, I'm
> not happy about that. As a user, I might not be happy either, if one of
> the build systems doesn't actually work in a Boost release.
>
> Regarding CMake as a candidate build system, I'm not convinced that the
> switch would benefit Boost in terms of "new blood" or something. I don't
> think the build system is something that is keeping millions of
> developers out there from contributing to Boost, as being advertised. It
> might be one, though probably not the major point, but I don't think
> anything will change e.g. wrt. maintenance if we switch right now. Most
> of the work doesn't even touch the build system or comes down to copying
> and pasting a piece of jamfile.
>
> I recognize that CMake has gained popularity and it is easier to find
> support for it online. But I know that more than once I've been puzzled
> about how to do one thing or the other in it, much like with
> Boost.Build. So as a Boost developer, there may be a slight plus on
> CMake side for me, but absolutely not worth the damage that has been
> inflicted on Boost already on the road to it. As a Boost user I really
> don't care as I never ever integrate third party projects into my
> project build system as I consider that a broken approach in the first
> place.

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

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