On Wed, 2017-07-19 at 14:37 +0200, Raffi Enficiaud via Boost wrote:

Le 19.07.17 à 03:09, Louis Dionne via Boost a écrit :

...

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

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.)

...

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

...

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/listinfo.cgi/b oost

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

On Wed, 2017-07-19 at 17:06 +0200, Raffi Enficiaud via Boost wrote:

Le 19.07.17 à 16:39, paul via Boost a écrit :

...

On Wed, 2017-07-19 at 14:37 +0200, Raffi Enficiaud via Boost wrote:

...

Le 19.07.17 à 03:09, Louis Dionne via Boost a écrit :

...

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

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.

...

...

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

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