[boost] Strawman proposals for CMake support

[Louis Dionne via Boost]

Hi,

I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
different advantages and disadvantages:

(1) Users have a hard time integrating Boost into their build system,
which is CMake more often than not.

(2) Prospective Boost developers are sometimes driven away from
submitting because they would have to learn Boost.Build, which
is not widely used and has a limited knowledge base.

FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
look something like:

1. We start requiring that new libraries support both Boost.Build
and CMake.

2. We start adding CMake support to existing libraries.
This will take time.
2.1 We start moving our infrastructure to be CMake-based.

3. We release Boost with dual support for a while, letting time
for things to bake.

4. We remove the requirement that Boot libraries can be built
with B2. Libraries (existing and new ones) are free to provide
such support, but they are not required to.

This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
at [1]. This has the following advantages (in the long term):
- Less technical debt because we only have one "official" build
system to maintain.
- The build system is uniform across all of Boost, which means
it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.

However, it has the following drawbacks:
- We'll need to do a wholesale migration to build system XYZ when
CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
Boost.Build


SECOND PROPOSAL
===============
The second proposal is to make Boost into an almost build-system
agnostic collection of libraries. Basically,

1. Provide CMake package config files for all Boost libraries so that
they can be used from CMake (either automatically, manually, or a
mixture of both). This could be based on Peter Dimov's work at [2]
(or [3], not sure which one is most current).

2. Make it possible to build CMake-based projects from Boost.Build, or
the other way around, or provide a build system agnostic script to
build all of Boost. This way, Boost libraries can decide whether
they want to support B2 or CMake.

This has the following advantages:
- Possibly easier to implement
- We could possibly support other build systems too (e.g. if a
Boost author really wants to use scons for his/her library)
- We don't have to do a wholesale move to XYZ when CMake is not
cool anymore

I see the following disadvantages:
- Boost's infrastructure could grow more complex as a result
- Our build system would be less uniform
- We would have to depend on all the build systems that we want
Boost libraries to be usable with


My personal preference is towards the first option, since I
think it would be simpler in the long term. I could certainly
be convinced otherwise.

There are probably other ways we can solve problems (1) and (2)
exposed above. There are also certainly advantages and
disadvantages that I forgot to mention above. I'd love to get
some feedback on those two approaches and see whether one of
them (or something else completely) can get some consensus on
this list.

Cheers,
Louis

[1]: https://github.com/boost-cmake/bcm
[2]: https://github.com/pdimov/boost-cmake-demo-2
[3]: https://github.com/pdimov/boost-cmake-demo




--
View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4696989.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[Stefan Seefeld via Boost]

Hi Louis,

while (as should be obvious) I'm strongly favouring the second proposal
(if I had to pick between the two), there are nonetheless points I'd
like to add to the rest of the message. I hope that doesn't dilute the
rest of it.

Post by Louis Dionne via Boost
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with

I keep reading various "analyses" about where the supposed pain points
are with the current Boost infrastructure, and following that, what
requirements should be met by any future version. But all too often, the
discussion then jumps to solutions, without ever consolidating on the
problem analysis. At least it's my impression that there are multiple
"camps" of users all arguing from very different perspectives,
representing different "development cultures".

Post by Louis Dionne via Boost
(1) Users have a hard time integrating Boost into their build system,
which is CMake more often than not.

Here is one of the fault lines: what is meant by "integrating Boost" ?
Some have argued that it ought to be possible to actually build Boost as
part of another project (thus integrating means the build system. For
others, it merely means the ability to build their own project with
Boost as an external (precompiled) dependency. How frequent are these
two requests, and how important is it for Boost to meet them ?(2)
Prospective Boost developers are sometimes driven away from

Post by Louis Dionne via Boost
submitting because they would have to learn Boost.Build, which
is not widely used and has a limited knowledge base.

I agree.

Post by Louis Dionne via Boost
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
and CMake.

(Why ? If you decide to move to CMake, why requiring new libraries to
support anything other than CMake ?)

Post by Louis Dionne via Boost
2. We start adding CMake support to existing libraries.
This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
for things to bake.
4. We remove the requirement that Boot libraries can be built
with B2. Libraries (existing and new ones) are free to provide
such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
- Less technical debt because we only have one "official" build
system to maintain.
- The build system is uniform across all of Boost, which means
it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
- We'll need to do a wholesale migration to build system XYZ when
CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
Boost.Build
SECOND PROPOSAL
===============
The second proposal is to make Boost into an almost build-system
agnostic collection of libraries. Basically,
1. Provide CMake package config files for all Boost libraries so that
they can be used from CMake (either automatically, manually, or a
mixture of both). This could be based on Peter Dimov's work at [2]
(or [3], not sure which one is most current).
2. Make it possible to build CMake-based projects from Boost.Build, or
the other way around, or provide a build system agnostic script to
build all of Boost. This way, Boost libraries can decide whether
they want to support B2 or CMake.
- Possibly easier to implement
- We could possibly support other build systems too (e.g. if a
Boost author really wants to use scons for his/her library)
- We don't have to do a wholesale move to XYZ when CMake is not
cool anymore

All true.

Post by Louis Dionne via Boost
- Boost's infrastructure could grow more complex as a result
- Our build system would be less uniform

In fact, if we go to the extreme, there wouldn't be a single "boost
build system" any longer. There would be a standard (a set of
conventions) for

* naming generated files
* directory structure
* required documentation
* entry points to trigger a build / test run
* etc.

all to encapsulate the actual build process of individual libraries,
while still providing the same consistency to Boost users. (Note that
this does not in itself open the door for arbitrary build tools to be
used. That would be a separate, orthogonal discussion.)

Post by Louis Dionne via Boost
- We would have to depend on all the build systems that we want
Boost libraries to be usable with

Now this is quite fuzzy again. Your implied requirement seems to be that
every user may want to build boost, as a whole, and thus will need all
the tools. I think this is nuts.
The first problem is again that you think of Boost as a single entity.
While that has some appeal to some (for example for legal reasons), I
think technically we should really start thinking about Boost libraries
as independent components, so a "Boost user" really becomes a
"Boost.Compute" user or a "Boost.FileSystem" user, etc., which massively
reduces the problem.
Second, most "users" don't need to build the Boost library they are
using, or at least, they don't need to build it as an integral part of
whatever other project they are working on. So they could treat it the
same way as any other third-party dependency.
Thirdly, yes, if we allow different build tools to be used, it means
that those who want to build these libs will need to adapt. I simply
trust that the individual (Boost) library communities can figure out
much better what tools suite them best than what any top-down steering
committee could.


Stefan

[Raffi Enficiaud via Boost]

Post by Louis Dionne via Boost
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
(1) Users have a hard time integrating Boost into their build system,
which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
submitting because they would have to learn Boost.Build, which
is not widely used and has a limited knowledge base.
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
and CMake.
2. We start adding CMake support to existing libraries.
This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
for things to bake.
4. We remove the requirement that Boot libraries can be built
with B2. Libraries (existing and new ones) are free to provide
such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
- Less technical debt because we only have one "official" build
system to maintain.
- The build system is uniform across all of Boost, which means
it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
- We'll need to do a wholesale migration to build system XYZ when
CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
Boost.Build

I personally believe that "anything" between the tool (cmake or
boost.build) and the developers should be avoided, whether it is a "good
idea" or not. So I will not be in favour of libraries such as, no
offense (**), BCM.

I would welcome a tool that dissects the Jamfiles and generates even a
rough/approximate CMakeLists.txt to start with.

But I would "really" rather focus on the interface between the
superproject and the libraries, and among the libraries themselves to
cover the inner dependencies (flow of information basically: expected
targets, naming conventions, build variants, etc).

Concerning the infrastructure, it would be good to list what should be
addressed there (servers, doc generation, runners, CI, dashboard, etc).
I believe most of the people do not know what it involves, and we sadly
lost Rene in this.

To summarize: I would like to focus on the "CMakeLists.txt" interface
rather than the implementation, because this is the big unknown to me
right now, and the infrastructure should receive enough attention
otherwise it will kill the intent.

I can volunteer for the infrastructure.


(**) (just in case my wording for "excluding" a proposal is not
inclusive enough.)

Post by Louis Dionne via Boost
SECOND PROPOSAL
===============
The second proposal is to make Boost into an almost build-system
agnostic collection of libraries. Basically,
1. Provide CMake package config files for all Boost libraries so that
they can be used from CMake (either automatically, manually, or a
mixture of both). This could be based on Peter Dimov's work at [2]
(or [3], not sure which one is most current).
2. Make it possible to build CMake-based projects from Boost.Build, or
the other way around, or provide a build system agnostic script to
build all of Boost. This way, Boost libraries can decide whether
they want to support B2 or CMake.

This sounds to me like designing a "build generator" (*) ... for a
"build generator" (boost.build or cmake). Or a meta-builder for a
meta-builder ...
The idea itself might be appealing but sounds bad in the end. If the
intent is to ease the development and shipping of boost libraries, then
adding a layer between the developer and cmake core functionalities is
not helping, and the tool will be just a subset of what cmake can do.

To summarize: I do not like this proposal.

(*) choose the name of your liking

Thanks,
Raffi

Post by Louis Dionne via Boost
- Possibly easier to implement
- We could possibly support other build systems too (e.g. if a
Boost author really wants to use scons for his/her library)
- We don't have to do a wholesale move to XYZ when CMake is not
cool anymore
- Boost's infrastructure could grow more complex as a result
- Our build system would be less uniform
- We would have to depend on all the build systems that we want
Boost libraries to be usable with
My personal preference is towards the first option, since I
think it would be simpler in the long term. I could certainly
be convinced otherwise.
There are probably other ways we can solve problems (1) and (2)
exposed above. There are also certainly advantages and
disadvantages that I forgot to mention above. I'd love to get
some feedback on those two approaches and see whether one of
them (or something else completely) can get some consensus on
this list.
Cheers,
Louis
[1]: https://github.com/boost-cmake/bcm
[2]: https://github.com/pdimov/boost-cmake-demo-2
[3]: https://github.com/pdimov/boost-cmake-demo
--
View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4696989.html
Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.or

[paul via Boost]

Post by Louis Dionne via Boost
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
(1) Users have a hard time integrating Boost into their build system,
    which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
    submitting because they would have to learn Boost.Build, which
    is not widely used and has a limited knowledge base.
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
   and CMake.
2. We start adding CMake support to existing libraries.
   This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
   for things to bake.
4. We remove the requirement that Boot libraries can be built
   with B2. Libraries (existing and new ones) are free to provide
   such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
- Less technical debt because we only have one "official" build
  system to maintain.
- The build system is uniform across all of Boost, which means
  it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
- We'll need to do a wholesale migration to build system XYZ when
  CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
  Boost.Build

I personally believe that "anything" between the tool (cmake or 
boost.build) and the developers should be avoided, whether it is a "good 
idea" or not. So I will not be in favour of libraries such as, no 
offense (**), BCM.

The point of BCM is not to abstract away the tool(although some developers
would like it to do that). Only to provide some functions for the boilerplate
in involved in generation of package configuration, to help provide
consistency with the testing, and provide support for documentation(ss cmake
does not provide modules for boost documentation).

I would welcome a tool that dissects the Jamfiles and generates even a 
rough/approximate CMakeLists.txt to start with.
But I would "really" rather focus on the interface between the 
superproject and the libraries, and among the libraries themselves to 
cover the inner dependencies (flow of information basically: expected 
targets, naming conventions, build variants, etc).

I think any cmake should follow closely this:

https://github.com/boost-cmake/boost

Concerning the infrastructure, it would be good to list what should be 
addressed there (servers, doc generation, runners, CI, dashboard, etc). 
I believe most of the people do not know what it involves, and we sadly 
lost Rene in this.
To summarize: I would like to focus on the "CMakeLists.txt" interface 
rather than the implementation, because this is the big unknown to me 
right now, and the infrastructure should receive enough attention 
otherwise it will kill the intent.
I can volunteer for the infrastructure.
(**) (just in case my wording for "excluding" a proposal is not 
inclusive enough.)

Post by Louis Dionne via Boost
SECOND PROPOSAL
===============
The second proposal is to make Boost into an almost build-system
agnostic collection of libraries. Basically,
1. Provide CMake package config files for all Boost libraries so that
   they can be used from CMake (either automatically, manually, or a
   mixture of both). This could be based on Peter Dimov's work at [2]
   (or [3], not sure which one is most current).
2. Make it possible to build CMake-based projects from Boost.Build, or
   the other way around, or provide a build system agnostic script to
   build all of Boost. This way, Boost libraries can decide whether
   they want to support B2 or CMake.

This sounds to me like designing a "build generator" (*) ... for a 
"build generator" (boost.build or cmake). Or a meta-builder for a 
meta-builder ...
The idea itself might be appealing but sounds bad in the end. If the 
intent is to ease the development and shipping of boost libraries, then 
adding a layer between the developer and cmake core functionalities is 
not helping, and the tool will be just a subset of what cmake can do.
To summarize: I do not like this proposal.
(*) choose the name of your liking
Thanks,
Raffi

Post by Louis Dionne via Boost
- Possibly easier to implement
- We could possibly support other build systems too (e.g. if a
  Boost author really wants to use scons for his/her library)
- We don't have to do a wholesale move to XYZ when CMake is not
  cool anymore
- Boost's infrastructure could grow more complex as a result
- Our build system would be less uniform
- We would have to depend on all the build systems that we want
  Boost libraries to be usable with
My personal preference is towards the first option, since I
think it would be simpler in the long term. I could certainly
be convinced otherwise.
There are probably other ways we can solve problems (1) and (2)
exposed above. There are also certainly advantages and
disadvantages that I forgot to mention above. I'd love to get
some feedback on those two approaches and see whether one of
them (or something else completely) can get some consensus on
this list.
Cheers,
Louis
[1]: https://github.com/boost-cmake/bcm
[2]: https://github.com/pdimov/boost-cmake-demo-2
[3]: https://github.com/pdimov/boost-cmake-demo
--
View this message in context: http://boost.2283326.n4.nabble.com/Strawman-
proposals-for-CMake-support-tp4696989.html
Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/b
oost

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

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

[Raffi Enficiaud via Boost]

Post by paul via Boost

Post by Raffi Enficiaud via Boost

Post by Louis Dionne via Boost
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
(1) Users have a hard time integrating Boost into their build system,
which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
submitting because they would have to learn Boost.Build, which
is not widely used and has a limited knowledge base.
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
and CMake.
2. We start adding CMake support to existing libraries.
This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
for things to bake.
4. We remove the requirement that Boot libraries can be built
with B2. Libraries (existing and new ones) are free to provide
such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
- Less technical debt because we only have one "official" build
system to maintain.
- The build system is uniform across all of Boost, which means
it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
- We'll need to do a wholesale migration to build system XYZ when
CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
Boost.Build

I personally believe that "anything" between the tool (cmake or
boost.build) and the developers should be avoided, whether it is a "good
idea" or not. So I will not be in favour of libraries such as, no
offense (**), BCM.

The point of BCM is not to abstract away the tool(although some developers
would like it to do that). Only to provide some functions for the boilerplate
in involved in generation of package configuration, to help provide
consistency with the testing, and provide support for documentation(ss cmake
does not provide modules for boost documentation).

What I also really dislike in this approach is to have a very hard
dependencies to whatever library that is lying in the superproject. My
goal is to be able to distribute boost.test (library and tests parts)
independently of boost as well.

Again that is to me the core of the problem: what CMake variables (or
interface) is needed in individual libraries and in the superproject to
have a decent global infrastructure?

Post by paul via Boost

Post by Raffi Enficiaud via Boost
I would welcome a tool that dissects the Jamfiles and generates even a
rough/approximate CMakeLists.txt to start with.
But I would "really" rather focus on the interface between the
superproject and the libraries, and among the libraries themselves to
cover the inner dependencies (flow of information basically: expected
targets, naming conventions, build variants, etc).

https://github.com/boost-cmake/boost

I will be honest: for the boost.test part, I will just rewrite
everything in there. This is just an empty shell that is providing the
very easy part, the tip of the iceberg.

And this is exactly my point that is not addressed in your reply: what
is supposed to be in the CMakeLists.txt in terms of inter dependencies?
For generating the doc? for testing and sharing their results? for being
able to unit test the CMakeLists.txt itself?

I believe, and this is certainly better done in another thread, that the
provided example does not address any of the main concerns, it just
declares a target, and adds a couple of dependencies to its interface.

That is not enough.

Raffi


_______________________________________________
Unsubscribe & other changes: http://li

[paul via Boost]

Post by paul via Boost

Post by Raffi Enficiaud via Boost

Post by Louis Dionne via Boost
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
(1) Users have a hard time integrating Boost into their build system,
    which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
    submitting because they would have to learn Boost.Build, which
    is not widely used and has a limited knowledge base.
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
   and CMake.
2. We start adding CMake support to existing libraries.
   This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
   for things to bake.
4. We remove the requirement that Boot libraries can be built
   with B2. Libraries (existing and new ones) are free to provide
   such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
- Less technical debt because we only have one "official" build
  system to maintain.
- The build system is uniform across all of Boost, which means
  it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
- We'll need to do a wholesale migration to build system XYZ when
  CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
  Boost.Build

I personally believe that "anything" between the tool (cmake or
boost.build) and the developers should be avoided, whether it is a "good
idea" or not. So I will not be in favour of libraries such as, no
offense (**), BCM.

The point of BCM is not to abstract away the tool(although some developers
would like it to do that). Only to provide some functions for the boilerplate
in involved in generation of package configuration, to help provide
consistency with the testing, and provide support for documentation(ss cmake
does not provide modules for boost documentation).

What I also really dislike in this approach is to have a very hard 
dependencies to whatever library that is lying in the superproject. My 
goal is to be able to distribute boost.test (library and tests parts) 
independently of boost as well.

Yes, it doesnt prevent that. In the standalone builds, BCM is just another
dependency the user would install(either manually or through a package
manager). This is why a file would start with `find_package(BCM)` so it will
search for the installed BCM, in the same way it would search for Boost.Config
when you call `find_package(boost_config)`.

Unless by independent, you mean zero dependencies. In this scenario, you can
call to `find_package(BCM)`, if not found do something else besides calling
the bcm module functions. Of course, creating zero dependency libraries should
not be the focus of the cmake. These are boost libraries that will be
integrated into boost infrastructure. I think it should up to the each
individual author to support zero-dependency library, while overall all boost
libraries should support standalone installation.

Again that is to me the core of the problem: what CMake variables (or 
interface) is needed in individual libraries and in the superproject to 
have a decent global infrastructure?

There is no variables that need to be defined, but we want to create a target
for the library, an alias target with the namespace, install the target and
header files, and generate the package configuration.

Post by paul via Boost

Post by Raffi Enficiaud via Boost
I would welcome a tool that dissects the Jamfiles and generates even a
rough/approximate CMakeLists.txt to start with.
But I would "really" rather focus on the interface between the
superproject and the libraries, and among the libraries themselves to
cover the inner dependencies (flow of information basically: expected
targets, naming conventions, build variants, etc).

https://github.com/boost-cmake/boost

I will be honest: for the boost.test part, I will just rewrite 
everything in there. This is just an empty shell that is providing the 
very easy part, the tip of the iceberg.
And this is exactly my point that is not addressed in your reply: what 
is supposed to be in the CMakeLists.txt in terms of inter dependencies? 

What do mean "interdependencies"? 

For generating the doc?

We will definitely need a cmake module for this as cmake doesn't support boost
doc directly.

for testing and sharing their results?

That should all happen within CTest.

for being 
able to unit test the CMakeLists.txt itself?

Building, testing and installing should be enough to test the cmake scripts.

I believe, and this is certainly better done in another thread, that the 
provided example does not address any of the main concerns, it just 
declares a target, and adds a couple of dependencies to its interface.
That is not enough.
Raffi
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
st

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

[paul via Boost]

Post by Louis Dionne via Boost
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
(1) Users have a hard time integrating Boost into their build system,
    which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
    submitting because they would have to learn Boost.Build, which
    is not widely used and has a limited knowledge base.
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
   and CMake.
2. We start adding CMake support to existing libraries.
   This will take time.
2.1 We start moving our infrastructure to be CMake-based.

We need to start by defining the use cases we want to support. That is we want
to support:

* Prebuilt libraries with `find_package`
* Integrated builds with `add_subdirectory`
* Bulding libraries standalone(ignoring cycles for now)
* Running tests with all of boost
* Running tests standalone
* Generating documenation...

Of course, as we start to move to cmake, we can start by getting the first
three cases done, and then move to integrating the tests. Then next phase
would be integrating the documentation. 

I think it important that we start outlining these goals. Especially since
users between prebuilt vs integrated builds don't agree, and we dont want to
support one while ignoring the other case. I think its important and feasible
to support both camps.



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

[Robert Ramey via Boost]

Proposals worthy of discussion. Might been a good idea to offer them
before the decision was announced.

Robert Ramey

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

[Louis Dionne via Boost]

Post by Robert Ramey via Boost
Proposals worthy of discussion. Might been a good idea to
offer them before the decision was announced.
Robert Ramey

You seem to be implying that I alone announced or took that decision,
which is a lot to bear. I'm trying to be constructive because I love
this community, I owe a lot to it, and I want it to flourish. Those
are things we both have in common, so let's build on them.

Louis




--
View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4696989p4697067.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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

[Jens Weller via Boost]

Gesendet: Mittwoch, 19. Juli 2017 um 03:09 Uhr
Betreff: [boost] Strawman proposals for CMake support
Hi,
I'd like to expose two strawman proposals for adding CMake support
to Boost. Both proposals would solve the following problems, with
(1) Users have a hard time integrating Boost into their build system,
which is CMake more often than not.
(2) Prospective Boost developers are sometimes driven away from
submitting because they would have to learn Boost.Build, which
is not widely used and has a limited knowledge base.
FIRST PROPOSAL
==============
The first proposal is to move completely to CMake and to render
Boost.Build support optional. The possible rollout plan would
1. We start requiring that new libraries support both Boost.Build
and CMake.
2. We start adding CMake support to existing libraries.
This will take time.
2.1 We start moving our infrastructure to be CMake-based.
3. We release Boost with dual support for a while, letting time
for things to bake.
4. We remove the requirement that Boot libraries can be built
with B2. Libraries (existing and new ones) are free to provide
such support, but they are not required to.
This would bring CMake to the status of "primary" build system
for Boost. This could be based on Paul Fultz's work in progress
- Less technical debt because we only have one "official" build
system to maintain.
- The build system is uniform across all of Boost, which means
it's easier for folks to maintain it and understand it.
- It gives maximal flexibility to CMake-based users.
- We'll need to do a wholesale migration to build system XYZ when
CMake is not cool anymore.
- It's harder to get buy-in from some developers that love
Boost.Build
SECOND PROPOSAL
===============
The second proposal is to make Boost into an almost build-system
agnostic collection of libraries. Basically,
1. Provide CMake package config files for all Boost libraries so that
they can be used from CMake (either automatically, manually, or a
mixture of both). This could be based on Peter Dimov's work at [2]
(or [3], not sure which one is most current).
2. Make it possible to build CMake-based projects from Boost.Build, or
the other way around, or provide a build system agnostic script to
build all of Boost. This way, Boost libraries can decide whether
they want to support B2 or CMake.
- Possibly easier to implement
- We could possibly support other build systems too (e.g. if a
Boost author really wants to use scons for his/her library)
- We don't have to do a wholesale move to XYZ when CMake is not
cool anymore
- Boost's infrastructure could grow more complex as a result
- Our build system would be less uniform
- We would have to depend on all the build systems that we want
Boost libraries to be usable with
My personal preference is towards the first option, since I
think it would be simpler in the long term. I could certainly
be convinced otherwise.
There are probably other ways we can solve problems (1) and (2)
exposed above. There are also certainly advantages and
disadvantages that I forgot to mention above. I'd love to get
some feedback on those two approaches and see whether one of
them (or something else completely) can get some consensus on
this list.

Response to these ideas, but also on the whole plan. boost.build has made boost independent from 3rd party build systems, its historically grown.
Its not your workhorse, thats C++, boost.build is a good part of your infrastructure, kind of the roads for your workhorse.

Looking at the recent survey from JetBrains, the C++ community at large is using different roads today:
https://www.jetbrains.com/research/devecosystem-2017/cpp/

5% boost build, 34% CMake. CMake added server mode this year, driving adoption from the IDE field (think VS/QtCreator here) to CMake.
Its good to see boost adopting to this.

One way that hasn't been discussed so far afaik is, that CMake also provides generators for build systems. One could write a CMake generator as an Adaptor to boost.build.
This only could be done by boost, would ensure that the generated boost.build files have a certain standard, the current infrastructure would suddenly still be useful, even when new libraries don't come with author supported boost.build files, boost would be able to generate these through the provided CMake files.

This knowledge could be useful in the future to adopt other build systems such as Meson too.

This solution would serve your current, boost.build based user base, as none would have to convert to CMake, while boost it self would be able to add CMake support to its libraries, offering two build systems instead of one. The current infrastructure would not need to be rewritten and no one would have to reinvent the wheel very often...

thanks,

Jens Weller


_______________________________________________
Unsubscribe & other changes: ht