[cmake] Pull request announcement

Mike Dev

14 Sep 2018 14 Sep '18

11:44 a.m.

Dear all, unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all). It appears that cmake efforts have yet again stalled. Last I heard was that everyone is waiting for BCM and the author of that library still tries to find a review manager. As we probably can't expect a full-fledged, boost-wide solution in the near future I'm trying it with a low-effort approach that will establish the minimal framework needed such that each library can be (where necessary) build with cmake and specify it's dependencies on other libraries (the latter being the really important part).

...

From that starting point a more holistic solution can then be developed step by step and (in most cases) library by library.

The only fundamental thing that needs to be decided by the community is a canonical naming scheme for the cmake targets that should be used by other libraries in their `target_link_libraries` call. For that I suggest that each library should provide an alias target called Boost:: (e.g. Boost::program_options) This also follows the naming scheme provided by cmake itself when using boost libraries that are installed on the system. Now about what I'm specifically going to put into the PRs: - I'll propose a trivial, top-level cmake file be added to the boost super project that doesn't do anything but look for CMakeLists.txt files in the root folder of each library and calls that file if present - Individual libraries get a simple CMakeLists.txt file that will - create an appropriate build target - INTERFACE library for header-only - STATIC for regular libraries - create an alias named Boost:: - build the library if necessary - specifying the minimum required c++ version - specify the local include directory (iirc that will always be "include") - specify all required dependencies This will not address - Testing - Installation - Creation of shared libraries - Creation of documentation - Special provisions for IDE integration In short: all the difficult stuff is left out ;) The goal is not to present a solution that can replace b2 but to have a minimal starting point upon which individual library authors or the community as a whole can make iterative improvements. If and when BCM (or an alternative) is accepted into boost, individual libraries can then easily switch to this full-fledged solution and of course any author can create a more complete CMake solution for his library at any time (as some already have). Finally, please don't nick-pick this to death. I'd like to have a more complete solution too, but it isn't coming, so let's do the minimum we can and go on from there. Note that the advantage of such a minimal solution is also that there are very few design decisions to make that may later turn out to be wrong and then create a maintenance burden. The only things that are visible on an interface level (and thus should remain reasonable stable) are: - The alias name Boost:: - How the public dependencies are specified: target_link_libraries( boost_ foo PUBLIC Boost::config Boost::core Boost::bar ) - The position of the CMakeLists.txt file in the library root folder All of this is long established best practice. Anything else can gradually be built on top of that. Best Michael

Show replies by date

Edward Diener

14 Sep 14 Sep

1:37 p.m.

On 9/14/2018 7:44 AM, Mike Dev via Boost wrote:

...

Dear all,

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms. Building non-header only libraries is actually much less of a problem for converting from Boost Build to CMake, even if it will get the vast majority of the comments.

Alexander Grund

2:05 p.m.

The major problem I see are the variants. - b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases CMake FindBoost solves this by requiring to set some variables to select a set of variants and set the appropriate aliases to this set. Think about how you reflect this in the CMake buildsystem. E.g. some libraries may depend explicitly on a static or dynamic version of another library (which can be expressed in bjam)

...

The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms. Building non-header only libraries is actually much less of a problem for converting from Boost Build to CMake, even if it will get the vast majority of the comments This won't be to bad either once the variants problem above is solved. CTest is quite powerful so except for a few corner cases I expect it to be straight forward.

Roger Leigh

3:40 p.m.

On 14/09/18 15:05, Alexander Grund via Boost wrote:

...

The major problem I see are the variants.

- b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases

CMake fundamentally doesn't work this way. Nor do any other build systems I'm aware of. It's unique to b2. I do not think it useful to require this of any replacement build system in consequence. Especially when it's an initial minimalistic support as proposed here. The variant naming strategy brings a lot of pain and it's something I personally always turn off when I can, because all those name variants result in having to hardcode b2-specific mappings for all the combinations in every build system other than b2, **because only b2 defines the names this way**. It's truly horrible, and I don't know why it's liked so much within the boost community. Am I the only one who suffers so much from it having to integrate it with other systems on multiple platforms? Regards, Roger

Rene Rivera

3:47 p.m.

On Fri, Sep 14, 2018 at 10:40 AM Roger Leigh via Boost < boost@lists.boost.org> wrote:

...

On 14/09/18 15:05, Alexander Grund via Boost wrote: The variant naming strategy brings a lot of pain and it's something I personally always turn off when I can, because all those name variants result in having to hardcode b2-specific mappings for all the combinations in every build system other than b2, **because only b2 defines the names this way**. It's truly horrible, and I don't know why it's liked so much within the boost community. Am I the only one who suffers so much from it having to integrate it with other systems on multiple platforms?

Clarification.. It's not b2 doing this. It's the build scripts for building Boost. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Peter Dimov

3:52 p.m.

Roger Leigh wrote:

...

It's truly horrible, and I don't know why it's liked so much within the boost community.

It's not liked at all. The Boost community is as wrong on this issue as the C++ community is. :-) The idea here is to prevent inadvertent linking to the wrong variant, with the associated nasty ODR problems that result. This comes somewhat more naturally to Windows developers who are accustomed to not being able to link debug to release and libraries using static runtime to libraries using dynamic runtime (and of course 32 bit to 64 bit). Since traditionally compilers don't enforce ODR and things mostly appear to work regardless, the problem doesn't attract much attention. You linked to the preinstalled Boost.System 1.53 built with C++03/release instead of the just built 1.64 with C++14/debug? No problem, everything works fine. Until it doesn't. This by the way has nothing to do with the proposed minimal CMake support, which builds the library as a subproject with whatever settings the main project uses and doesn't care about naming strategies.

Niall Douglas

4:13 p.m.

...

...
The major problem I see are the variants.

- b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases

CMake fundamentally doesn't work this way.

Via targets and modern cmake, it very easily can. This is my single biggest objection to the approach taken for Boost cmake to date in fact. It has stuck with legacy cmake design patterns of configuration knobs and multiple invocations to generate variants. But I can probably suck down this objection, if nothing else is problematic in Boost cmake during its peer review. Niall

Mateusz Loskot

4:31 p.m.

On Fri, 14 Sep 2018 at 18:14, Niall Douglas via Boost wrote:

...

...
...
The major problem I see are the variants.

- b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases

CMake fundamentally doesn't work this way.

Via targets and modern cmake, it very easily can.

Folks, If this thread is going to be another general discussion about what CMake can or can not do in comparison go Boost.Build, or why person X prefers one over another and why person Y disagrees, then please, FFS, change the subject line, at least. Thank you! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Richard

18 Sep 18 Sep

8:31 p.m.

In article , Roger Leigh via Boost writes:

...

On 14/09/18 15:05, Alexander Grund via Boost wrote:

...
The major problem I see are the variants.

- b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases

CMake fundamentally doesn't work this way. Nor do any other build systems I'm aware of. It's unique to b2. I do not think it useful to require this of any replacement build system in consequence. Especially when it's an initial minimalistic support as proposed here.

...

[...] Am I the only one who suffers so much from it having to integrate it with other systems on multiple platforms?

Nope. Been there, done that. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Terminals Wiki http://terminals-wiki.org The Computer Graphics Museum http://ComputerGraphicsMuseum.org Legalize Adulthood! (my blog) http://LegalizeAdulthood.wordpress.com

Edward Diener

14 Sep 14 Sep

6:02 p.m.

On 9/14/2018 10:05 AM, Alexander Grund via Boost wrote:

...

The major problem I see are the variants.

- b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases

CMake FindBoost solves this by requiring to set some variables to select a set of variants and set the appropriate aliases to this set.

Think about how you reflect this in the CMake buildsystem. E.g. some libraries may depend explicitly on a static or dynamic version of another library (which can be expressed in bjam)

...
The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms. Building non-header only libraries is actually much less of a problem for converting from Boost Build to CMake, even if it will get the vast majority of the comments This won't be to bad either once the variants problem above is solved. CTest is quite powerful so except for a few corner cases I expect it to be straight forward.

CTest has absolutely no notion of compile-time testing. This was mentioned to CMake on their mailing list a long time ago and got the usual yawns from the CMake people.

Robert Ramey

7:46 p.m.

On 9/14/18 11:02 AM, Edward Diener via Boost wrote:

...

CTest has absolutely no notion of compile-time testing. This was mentioned to CMake on their mailing list a long time ago and got the usual yawns from the CMake people.

It can be done. I needed for the CMake version of the script which runs the tests for the safe numerics library. It's a little kludgy. But it does work and it's inside the CMake black box so it solves the problem in acceptable manner. Robert Ramey

...

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

Robert Ramey

7:49 p.m.

On 9/14/18 11:02 AM, Edward Diener via Boost wrote:

...

CTest has absolutely no notion of compile-time testing. This was mentioned to CMake on their mailing list a long time ago and got the usual yawns from the CMake people.

Right. I needed this for the CMake testing of the safe numerics library. Found the hack to make it work. A little kludgy be works find and is inside the CMake black box so that's not really a problem. Robert Ramey

...

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

Alexander Grund

17 Sep 17 Sep

11:09 a.m.

...

...
This won't be to bad either once the variants problem above is solved. CTest is quite powerful so except for a few corner cases I expect it to be straight forward.

CTest has absolutely no notion of compile-time testing. This was mentioned to CMake on their mailing list a long time ago and got the usual yawns from the CMake people. This is not entirely true. I myself did write such tests. It is simply an invocation of "${CMAKE_COMMAND} --build . --config $<CONFIG> --target ..." added with `add_test` and setting the property `WILL_FAIL` to TRUE. I even went a step further and added a macro which will add 2 targets, where one as a preprocessor macro defined. The test then checks that compilation succeeds when the macro is not defined and it doesn't when it is. This makes sure the "faulty" code is indeed the source of error. You could also use a regex to match the error.

Yes this is not as straight forward as it could be, but neither is the way in bjam: You need to call some macro/function/... and that does the magic.

Rene Rivera

12:30 p.m.

On Mon, Sep 17, 2018 at 6:09 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:

...

...
...
This won't be to bad either once the variants problem above is solved. CTest is quite powerful so except for a few corner cases I expect it to be straight forward.

CTest has absolutely no notion of compile-time testing. This was mentioned to CMake on their mailing list a long time ago and got the usual yawns from the CMake people. This is not entirely true. I myself did write such tests. It is simply an invocation of "${CMAKE_COMMAND} --build . --config $<CONFIG> --target ..." added with `add_test` and setting the property `WILL_FAIL` to TRUE. I even went a step further and added a macro which will add 2 targets, where one as a preprocessor macro defined. The test then checks that compilation succeeds when the macro is not defined and it doesn't when it is. This makes sure the "faulty" code is indeed the source of error. You could also use a regex to match the error.

Yes this is not as straight forward as it could be, but neither is the way in bjam: You need to call some macro/function/... and that does the magic.

Ha? === compile-fail my_test.cpp ; === -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Alexander Grund

12:33 p.m.

...

Yes this is not as straight forward as it could be, but neither is the way in bjam: You need to call some macro/function/... and that does the magic.

Ha?

=== compile-fail my_test.cpp ; ===

And compile-fail is a function, right? Same for CMake: `add_failing_compile_test(my_test.cpp)` (change the name to your liking) and that needs to be implemented. Probably 2-fold: One general, boost-wide version and 1 per library which e.g. automatically links against that library.

Rene Rivera

1 p.m.

On Mon, Sep 17, 2018, 7:33 AM Alexander Grund wrote:

...

Yes this is not as straight forward as it could be, but neither is the

...
way in bjam: You need to call some macro/function/... and that does the magic.

Ha?

=== compile-fail my_test.cpp ; ===

And compile-fail is a function, right? Same for CMake: `add_failing_compile_test(my_test.cpp)` (change the name to your liking) and that needs to be implemented. Probably 2-fold: One general, boost-wide version and 1 per library which e.g. automatically links against that library.

Yes, and it's built-in to b2. Something which the cmake/test developers are seemingly unwilling to add. Which was the original point of this thread branch.

...

Peter Dimov

14 Sep 14 Sep

2:20 p.m.

Edward Diener wrote:

...

On 9/14/2018 7:44 AM, Mike Dev via Boost wrote:

...
Dear all,

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms.

That's not what the proposed minimal support is about (IIUC). The goal here is for people to be able to use a local installation of Boost (as cloned from Github, perhaps as a submodule) from their CMake projects by including the top-level CMakeLists.txt and then linking to the appropriate imported targets. Tests, docs, are not in scope. Neither is building multiple variants, staging, or installation.

Edward Diener

6:05 p.m.

On 9/14/2018 10:20 AM, Peter Dimov via Boost wrote:

...

Edward Diener wrote:

...
On 9/14/2018 7:44 AM, Mike Dev via Boost wrote:

...
Dear all,

unless I'm encountering an overwhelming resistance to this idea here on > the ml, I intend to create a batch of PRs that introduce minimal cmake > support to a large subset of boost libraries (maybe even all).

The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms.

That's not what the proposed minimal support is about (IIUC). The goal here is for people to be able to use a local installation of Boost (as cloned from Github, perhaps as a submodule) from their CMake projects by including the top-level CMakeLists.txt and then linking to the appropriate imported targets.

Tests, docs, are not in scope. Neither is building multiple variants, staging, or installation.

In which case CMake support in Boost evidently means that Boost Build will continue as the means to do tests and build the docs. That is fine with me but must be understood by the Boost Steering Committee and Boost developers/maintainers as part of Boost using CMake.

Robert Ramey

7:51 p.m.

On 9/14/18 11:05 AM, Edward Diener via Boost wrote:

...

On 9/14/2018 10:20 AM, Peter Dimov via Boost wrote:

...
Edward Diener wrote:

...

...
That's not what the proposed minimal support is about (IIUC). The goal here is for people to be able to use a local installation of Boost (as cloned from Github, perhaps as a submodule) from their CMake projects by including the top-level CMakeLists.txt and then linking to the appropriate imported targets.

Tests, docs, are not in scope. Neither is building multiple variants, staging, or installation.

In which case CMake support in Boost evidently means that Boost Build will continue as the means to do tests and build the docs. That is fine with me but must be understood by the Boost Steering Committee and Boost developers/maintainers as part of Boost using CMake.

Hmmm - Where is the scope defined? I don't think there is a concensus on this. Robert Ramey

...

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

mike.dev＠gmx.de

15 Sep 15 Sep

8:11 a.m.

...

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Friday, September 14, 2018 8:05 PM To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] [cmake] Pull request announcement

On 9/14/2018 10:20 AM, Peter Dimov via Boost wrote:

...
Edward Diener wrote:

...
On 9/14/2018 7:44 AM, Mike Dev via Boost wrote:

...
Dear all,

unless I'm encountering an overwhelming resistance to this idea here on > the ml, I intend to create a batch of PRs that introduce minimal cmake > support to a large subset of boost libraries (maybe even all).

The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms.

That's not what the proposed minimal support is about (IIUC). The goal here is for people to be able to use a local installation of Boost (as cloned from Github, perhaps as a submodule) from their CMake projects by including the top-level CMakeLists.txt and then linking to the appropriate imported targets.

Tests, docs, are not in scope. Neither is building multiple variants, staging, or installation.

In which case CMake support in Boost evidently means that Boost Build will continue as the means to do tests and build the docs. That is fine with me but must be understood by the Boost Steering Committee and Boost developers/maintainers as part of Boost using CMake.

I'm pretty sure the desire of the steering committee, many users and probably A lot of boost maintainers is that b2 gets completely replaced by a cmake based solution someday (e.g. in the form of BCM). However, I as a user would be very happy to at least have a solution that covers 80% of my use cases and that can be implemented now (by me alone if necessary) instead of further hoping that this full replacement comes "soon"

Mateusz Loskot

6:01 p.m.

On Sat, 15 Sep 2018 at 10:11, mike via Boost wrote:

...

I'm pretty sure the desire of the steering committee, many users and probably A lot of boost maintainers is that b2 gets completely replaced by a cmake based solution someday (e.g. in the form of BCM).

Unless you poll the community the "pretty sureness" has no connection to the reality. I am a user and developer quite heavily sold to CMake I use CMake for Boost development. I would like to see CMake accepted as officially offered and supported build configuration. But, I do not expect CMake to replace Boost.Build. Despite that I quite often suffer from motion sickness when I have to write a non-trivial Jamfile script, I consider Boost.Build an excellent build system and I do rely on Boost.Build for Boost development developing and testing. <my-view-at-ideal-world> I would like to see - CMake and Boost.Build first class citizen build systems in Boost - each maintained by dedicated team devoted to one or the other - non-competing, but complementing Next, all references to Boost.Build and Jamfiles wiped out from the library requirements [1]. Instead, the whole community of Boost maintainers and teams of the respectful build configurations (ie. CMake and Boost.Build) should offer library author(s) any help required to integrate the libraries into the officially supported build systems. Build configurations are there as common layers glueing Boost libraires for practical convenience in development and usage, and they should be common collaborative responsibility. </my-view-at-ideal-world> FWIW, since substantial concern of library reviews are C++ code and documentation, only, lack of Jamfile-s is not a stopper preventing successful acceptance into Boost! The requirements [1] clearly states the build integration happens *after* the fact: "Once a library is accepted as part of the Boost C++ Libraries it is required that it integrate properly into the development, testing, documentation, and release processes." Then, Jamfile 'transitively' required via the testing policy [2] "A Jamfile to drive the regression tests for the library" The Boost.Build-related requirements for testing policy were established in times when no Travis CI/AppVeyor/CircleC/Azure Pipelines existed, but Boost heavily relied on in-house regression tests waterfall. Now, perhaps the requirement can shift the weight towards the CI services, make the Jamfile optional and participation in the Boost regression tests waterfall complementary. However, an update to the policies and requirements will be necessary in order to make CMake (or any other new build system) officially supported. [1] https://www.boost.org/development/requirements.html [2] https://www.boost.org/development/test.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Steven Watanabe

6:35 p.m.

AMDG On 09/15/2018 12:01 PM, Mateusz Loskot via Boost wrote:

...

<snip> FWIW, since substantial concern of library reviews are C++ code and documentation, only, lack of Jamfile-s is not a stopper preventing successful acceptance into Boost!

The requirements [1] clearly states the build integration happens *after* the fact:

Right. In practice, libraries often do not have Jamfiles when they are reviewed and it usually only merits a note that they need to be added before inclusion. In Christ, Steven Watanabe

Andrey Semashev

14 Sep 14 Sep

2:23 p.m.

On Fri, Sep 14, 2018 at 2:44 PM, Mike Dev via Boost wrote:

...

Dear all,

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

It appears that cmake efforts have yet again stalled. Last I heard was that everyone is waiting for BCM and the author of that library still tries to find a review manager. As we probably can't expect a full-fledged, boost-wide solution in the near future I'm trying it with a low-effort approach that will establish the minimal framework needed such that each library can be (where necessary) build with cmake and specify it's dependencies on other libraries (the latter being the really important part).

I think a Cmake support proposal should involve a more complete approach that supports the current Boost workflow, including building and testing, and offer an easy integration into users' projects. Any such proposal should go through a review (possibly, a joint review of multiple proposals). Whichever solution is accepted, it automatically rejects any other proposals (because, let's be honest, noone wants to do the job twice). Accepting an inferior solution without a review does a poor service to Boost libraries and prematurely shoots down other efforts.

Stefan Seefeld

2:27 p.m.

Hi Mike, On 2018-09-14 07:44 AM, Mike Dev via Boost wrote:

...

Dear all,

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

I don't want to come across as rude, but I have to admit that I'm quite annoyed about the still ongoing debate, where everyone remains enclosed in his own mindset. You can look up the arguments in the archives. I can't of course stop you from submitting PRs, but I'm not going to merge a new build logic into my repos if I don't feel comfortable maintaining them. Having to maintain the b2 infrastructure is already painful enough. I can't stress this enough, so I'm repeating it yet again: I'm not against new things added to Boost. I'm against them being added whole-sale, to all of the >150 libs at once. This issue can only be resolved by us collectively stopping to think (and act) as if Boost was a monolith. I don't mind what processes and tools other Boost projects use, but please don't force me to use yours. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

mike.dev＠gmx.de

4:14 p.m.

...

-----Original Message----- From: Boost On Behalf Of Stefan Seefeld via Boost Sent: Friday, September 14, 2018 4:27 PM

Hi Mike,

On 2018-09-14 07:44 AM, Mike Dev via Boost wrote:

...
Dear all,

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

I don't want to come across as rude, but I have to admit that I'm quite annoyed about the still ongoing debate, where everyone remains enclosed in his own mindset. You can look up the arguments in the archives.

...

I can't of course stop you from submitting PRs, but I'm not going to merge a new build logic into my repos if I don't feel comfortable maintaining them. Sure. I forgot what libraries you are maintaining. If you tell me I'll write a PR and you can tell me if you feel comfortable with maintaining it. We are talking about 5-10 lines of cmake code + one line per dependency (the way I tend to format them).I hope that will not be problem, but if it is,

Believe me, I have :( Which is why I'm not trying to be the next guy submitting a new proposal on how to switch from b2 to cmake, which again leads to nothing. I've come to accept that this won't happen in a time frame that is relevant for me/us (if ever) and my PRs (as well as the discussion about c++03 support that I started) are my 80/20 solution, that gives me 80% of what I need with 20 % (or less) of the effort a 100% solution would require. then - as you said - just don't accept it.

...

Having to maintain the b2 infrastructure is already painful enough. Which is the whole reason people want to use cmake

I can't stress this enough, so I'm repeating it yet again: I'm not against new things added to Boost. I'm against them being added whole-sale, to all of the >150 libs at once. This issue can only be resolved by us collectively stopping to think (and act) as if Boost was a monolith.

Sure, Ideally, each library would be completely independent. Unfortunately, that is not the case at all. For one, all boost libraries are distributed together, following a common release cycle and second,, there is an extremely tight coupling between a large part of the libraries (especially older ones). Doing anything that influences the interface to one library (be it the actual API/ABI or leaky "implementation details", such as the supported compilers, language standards, change in transitive dependencies or the build system) involuntarily effects other libraries in the boost eco system - much more so than it would a random collection of independent open source libraries. Imho it's not a problem of thinking/acting "as if". It is the hard reality that boost is not a collection of independent libraries that can operate independently. I'll support any effort that moves boost in that direction, but the last proposal I could find on the mailing list on that topic was pretty much shouted down. Personally, I really do think there is a dire need for rebooting boost in a way that reduces coupling and increases independency between the libraries, but as far as I can tell, everytime someone tries to effect any significant, large scale change in boost inertia wins.

...

I don't mind what processes and tools other Boost projects use, but please don't force me to use yours.

Whatever build system you are using "leaks" to your users, because it e.g. determines how the user can make sure, that your library is compiled with the same compile flags as the rest of the program or how transitive dependencies are communicated upwards. It also determines how easy it is to integrate your library in a package management system and so on. Obviously I can't force you to do anything, but cmake is not "my tool". For better or for worse, cmake has emerge as the common denominator - as far as anything is "common" in the c++ world - and life in the OS world just becomes so much easier if everyone supports a common default instead on insisting on their own proprietary solution.

...

Thanks,

Stefan

Best Mike

Peter Dimov

4:24 p.m.

mike wrote:

...

We are talking about 5-10 lines of cmake code + one line per dependency (the way I tend to format them).

I suggest you use my approach of including cmake/dependencies.cmake, which is generated by `boostdep --cmake <libname>`. See f.ex. https://github.com/pdimov/boost-cmake-demo/blob/master/libs/system/cmake/dep... https://github.com/pdimov/boost-cmake-demo/blob/master/libs/system/cmake/def... (except without 45-49) This would allow CMakeLists.txt to stay the same if dependencies change; it also allows overwriting dependencies.cmake wholesale, something that could potentially be automated in the future. I (somewhat arbitrarily) chose to use boost::libname as imported target name, not sure if Boost:: is better.

mike.dev＠gmx.de

4:34 p.m.

...

-----Original Message----- From: Boost On Behalf Of Peter Dimov via Boost Sent: Friday, September 14, 2018 6:25 PM To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] [cmake] Pull request announcement

mike wrote:

...
We are talking about 5-10 lines of cmake code + one line per dependency (the way I tend to format them).

I suggest you use my approach of including cmake/dependencies.cmake,

Frankly, I don't see the advantage to split such a trivial file: cmake_minimum_required(VERSION 3.5) project(boost-foo) add_library(boost_foo INTERFACE) add_library(Boost::foo alias boost_foo) target_include_directories(boost_foo INTERFACE include) target_link_libraries(boost_foo INTERFACE Boost::bar Boost::baz Boost::miaow ... ) That's it for a header only library (as I said, I won't deal with testing, installation etc) For a more complex file, I see the benefit of splitting it up

...

I (somewhat arbitrarily) chose to use boost::libname as imported target name, not sure if Boost:: is better.

Boost:: is what cmake is currently using when using find_package(Boost ...) Best Mike

Peter Dimov

4:52 p.m.

mike wrote:

...

Frankly, I don't see the advantage to split such a trivial file:

The advantage, as I already stated, is that when the dependencies change (which they do), you can just regenerate dependencies.cmake with boostdep (which can be automated) instead of editing CMakeLists.txt by hand.

mike.dev＠gmx.de

15 Sep 15 Sep

8:06 a.m.

...

-----Original Message----- From: Boost On Behalf Of Peter Dimov Sent: Friday, September 14, 2018 6:52 PM

mike wrote:

...
Frankly, I don't see the advantage to split such a trivial file:

The advantage, as I already stated, is that when the dependencies change (which they do), you can just regenerate dependencies.cmake with boostdep (which can be automated) instead of editing CMakeLists.txt by hand.

Well, personally I think that is backwards: Taking a new dependency should be a deliberate act that I manually document in my build file (many boost libraries already have far too many internal dependencies). Only then do I start to (directly) include headers from that dependency. But in the end, each library maintainer is of course free to reject / alter / extend the cmake file I'm going to propose. Again, the only important thing is to have a common naming convention for the public targets

Peter Dimov

4:09 p.m.

mike wrote:

...

Well, personally I think that is backwards: Taking a new dependency should be a deliberate act that I manually document in my build file (many boost libraries already have far too many internal dependencies). Only then do I start to (directly) include headers from that dependency.

That's not really how things work in Boost, for better or worse. And of course dependences sometimes go down, not up.

...

But in the end, each library maintainer is of course free to reject / alter / extend the cmake file I'm going to propose.

Sure, but what we're discussing here is the ongoing maintenance of the cmake file, keeping it up to date. There's another approach; add to Travis a configuration that uses CMake to test the library, without running `b2 headers` first. Since the header links won't be present, a missing dependency will immediately cause an error due to the library not being in the include path. The problem here is that libraries often need more dependencies to run the tests, so it might not be possible to use the whole test suite as-is, but for libraries where this is an issue, we could add a dedicated "cmake_test.cpp" that's lighter but does at least test whether the library compiles at all.

Stefan Seefeld

14 Sep 14 Sep

5:42 p.m.

On 2018-09-14 12:14 PM, mike via Boost wrote:

...

Whatever build system you are using "leaks" to your users, because it e.g. determines how the user can make sure, that your library is compiled with the same compile flags as the rest of the program or how transitive dependencies are communicated upwards. It also determines how easy it is to integrate your library in a package management system and so on.

I know all that. That's indeed part of a library maintainer's responsibility.

...

Obviously I can't force you to do anything, but cmake is not "my tool". For better or for worse, cmake has emerge as the common denominator - as far as anything is "common" in the c++ world - and life in the OS world just becomes so much easier if everyone supports a common default instead on insisting on their own proprietary solution.

Sorry, that never worked. New tools and processes appear (and disappear !) all the time. That's no reason to impose on any project maintainer to switch to whatever is en vogue. Again, I'm not arguing for or against a specific set of tools. I'm arguing against the very idea to force >150 projects to adopt the same. So, to get back to the original announcement: all your effort and good intentions notwithstanding, I believe you shouldn't even try to contribute such infrastructure, unless of course your are fully committing to maintain it all, i.e. allow me to forward each and every bug report I'm going to receive on my projects that is related to that build logic. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Mateusz Loskot

5:55 p.m.

On Fri, 14 Sep 2018 at 19:42, Stefan Seefeld via Boost wrote:

...

On 2018-09-14 12:14 PM, mike via Boost wrote:

...
Obviously I can't force you to do anything, but cmake is not "my tool". For better or for worse, cmake has emerge as the common denominator - as far as anything is "common" in the c++ world - and life in the OS world just becomes so much easier if everyone supports a common default instead on insisting on their own proprietary solution.

Sorry, that never worked. New tools and processes appear (and disappear !) all the time. That's no reason to impose on any project maintainer to switch to whatever is en vogue. Again, I'm not arguing for or against a specific set of tools. I'm arguing against the very idea to force >150 projects to adopt the same.

So, to get back to the original announcement: all your effort and good intentions notwithstanding, I believe you shouldn't even try to contribute such infrastructure, unless of course your are fully committing to maintain it all, i.e. allow me to forward each and every bug report I'm going to receive on my projects that is related to that build logic.

Perhaps, I will manage to help to clarify Stefan's point with some experience from our, Stefan and mine, collaboration on Boost.GIL. I recently joined Boost.GIL team as developer and maintainer. I immediately submitted a contributor-oriented CMake support, and Stefan accepted it. However, I am the one in GIL team responsible to maintain it. If a bus hits me, all CMakeLists.txt I added will be removed. Unless, new developer arrives interested and capable to maintain CMake support for GIL. That same 'policy' applies to Faber [1] support, which is Stefan's responsibility to maintain for GIL. [1] https://github.com/stefanseefeld/faber Historically, Boost.Build situation is very different - I think I'm safe to say it is Boost's build system of choice. We, as maintainers of Boost.GIL maintainers, are de-facto required to (know how to) maintain GIL's Jamfile-s. Now, that special sitaution of Boost.Build is something some/manu object or conclude with "well, if Boost.Build has got acceptance, then let CMake get accepted too". Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

mike.dev＠gmx.de

15 Sep 15 Sep

11:24 a.m.

...

-----Original Message----- From: Boost On Behalf Of Stefan Seefeld via Boost Sent: Friday, September 14, 2018 7:43 PM

On 2018-09-14 12:14 PM, mike via Boost wrote:

[...] Sorry, that never worked. New tools and processes appear (and disappear !) all the time. That's no reason to impose on any project maintainer to switch to whatever is en vogue.

Actually, it works quite well outside of boost. As I said, we are not talking about following the latest hype here but the de-facto standard for cross-platform C++ projects.

...

Again, I'm not arguing for or against a specific set of tools. I'm arguing against the very idea to force >150 projects to adopt the same.

Imho, as long as boost tries to provide a joint release and distribution mechanism and there is such a tight coupling between the libs, at least the public interface (how do I tell a library, which compiler and flags to use and how does a library tell me what it's dependencies are) should be standardized just as it is now. Also, far more than 150 Projects have adopted cmake (or at least provide a cmake interface).

...

So, to get back to the original announcement: all your effort and good intentions notwithstanding, I believe you shouldn't even try to contribute such infrastructure, unless of course your are fully committing to maintain it all, i.e. allow me to forward each and every bug report I'm going to receive on my projects that is related to that build logic.

As long as we are talking about genuine bug reports and not feature request: Sure

...

Stefan

Mike

Peter Dimov

14 Sep 14 Sep

3:56 p.m.

Mike Dev wrote:

...

- STATIC for regular libraries

Why not look at "BUILD_SHARED_LIBS"?

Niall Douglas

3:59 p.m.

...

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

I would oppose this PR for the following reasons: 1. A lot of work has been invested by many people in the Boost cmake implementation, which is ready for peer review. It would do its authors a great disservice to push through some stop gap. Instead, the OP should consider review managing the Boost cmake implementation if he is so keen on this. That's the blocker - lack of review manager. Not that the work hasn't been done. 2. cmake is a big move for Boost. Submitting a stopgap without proper community review is not in keeping with Boost's established precedent and norms. 3. It is the wrong stopgap solution at a technical level. The correct stopgap solution is an imported targets cmake file which refers to the build outputs generated by Boost.Build. Possibly, Boost.Build should generate it, but I can see worth in a Python script which can take a release distro and generate from that an imported targets cmake. Even better if said Python script can be run as part of release management, and the imported targets cmake file gets shipped with the release distro. I applaud the OP's eagerness. But he's proposing the wrong solution, and for the wrong reasons. Niall

mike.dev＠gmx.de

4:24 p.m.

...

-----Original Message----- From: Boost On Behalf Of Niall Douglas Sent: Friday, September 14, 2018 6:00 PM Cc: Niall Douglas Subject: Re: [boost] [cmake] Pull request announcement

...
unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

I would oppose this PR for the following reasons:

1. A lot of work has been invested by many people in the Boost cmake implementation, which is ready for peer review. It would do its authors a great disservice to push through some stop gap.

It has been ready for how long now? If a real solution doesn't come for years and years, a stop-gap solution might be better than just hoping for some more years for something that might never come

...

Instead, the OP should consider review managing the Boost cmake implementation if he is so keen on this. That's the blocker - lack of review manager. Not that the work hasn't been done.

Am I allowed to be a review manager even though I'm not a library maintainer? If so - sure, what do I have to do? Proposing PRs to individual libraries seemed the only way for me as an outsider to help with moving anything forward.

...

2. cmake is a big move for Boost. Submitting a stopgap without proper community review is not in keeping with Boost's established precedent and norms.

Afaik, every library is allowed to support any build system in addition To b2 that it wants. So what is the problem? Contrary to BCM, I'm not Offering a replacement for b2 - that is just beyond my capabilities and frankly beyond the time I can spend on this.

...

3. It is the wrong stopgap solution at a technical level. The correct stopgap solution is an imported targets cmake file which refers to the build outputs generated by Boost.Build. Possibly, Boost.Build should generate it, but I can see worth in a Python script which can take a release distro and generate from that an imported targets cmake. Even better if said Python script can be run as part of release management, and the imported targets cmake file gets shipped with the release distro.

That requires a) more effort and b) only solves the consummation side. It e.g. doesn't solve the problem of properly propagating build flags from my cmake project to the boost libraries

...

I applaud the OP's eagerness. But he's proposing the wrong solution, and for the wrong reasons.

Sorry to hear that

...

Niall

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

Raffi Enficiaud

16 Sep 16 Sep

9:10 a.m.

On 14.09.18 13:44, Mike Dev via Boost wrote:

...

Dear all,

unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).

[snip]

Finally, please don't nick-pick this to death. I'd like to have a more complete solution too, but it isn't coming, so let's do the minimum we can and go on from there. Note that the advantage of such a minimal solution is also that there are very few design decisions to make that may later turn out to be wrong and then create a maintenance burden.

The only things that are visible on an interface level (and thus should remain reasonable stable) are:

[snip]

I have a working prototype: https://github.com/raffienficiaud/boost-cmake Please give a try, it is very easy to use and it is still working. It is honoring the inter-libraries dependencies. It has a nice design IMO, and is handling project dependencies in an ok fashion, with very little overhead. An additional plan was to integrate the automatic dependency tool discovery in it (made by Peter Dimov). Quickbook is here (compilation), and I am almost done with exposing functions to compile the doc of each project. There is something I was not able to achieve though: detecting the version of the CRT for Visual. This affects apparently some project dependencies (regex + libICU). I would be happy to discuss about this offline, with a set of interested people. In particular, the design is not intrusive and it lets library expose their cmake inside boost or independently. I stopped working on this some time ago because I was lacking time, but I am interested in resurrecting it, and it is on my todo list. Best, Raffi

Mike Dev

17 Sep 17 Sep

8:22 a.m.

...

-----Original Message----- From: Boost On Behalf Of Raffi Enficiaud via Boost Sent: Sunday, September 16, 2018 11:11 AM

...
I have a working prototype: https://github.com/raffienficiaud/boost-cmake

Please give a try, it is very easy to use and it is still working.

Thanks, I had a quick glance from my mobile, but didn't have the time to have a proper look. I'll do sometime this week. One early piece of feedback: I don't see why header-only libraries should be treated significantly different from normal libraries as far as cmake is concerned

...

[...] I would be happy to discuss about this offline, with a set of interested people. The issues on your github project seem a good place - or do you want to do this via email?

...

In particular, the design is not intrusive and it lets library expose their cmake inside boost or independently.

While non-intrusive design is a good thing for an external add-on, when you can't modify the original, I think boost should strive for a solution, where cmake is an integrated & independent part of each individual library. Best Mike

Raffi Enficiaud

6:18 p.m.

On 17.09.18 10:22, Mike Dev via Boost wrote:

...

...
-----Original Message----- From: Boost On Behalf Of Raffi Enficiaud via Boost Sent: Sunday, September 16, 2018 11:11 AM

...
I have a working prototype: https://github.com/raffienficiaud/boost-cmake

Please give a try, it is very easy to use and it is still working.

Thanks, I had a quick glance from my mobile, but didn't have the time to have a proper look. I'll do sometime this week. One early piece of feedback: I don't see why header-only libraries should be treated significantly different from normal libraries as far as cmake is concerned

...
[...] I would be happy to discuss about this offline, with a set of interested people. The issues on your github project seem a good place - or do you want to do this via email?

Thanks for your feedback, both work for me!

...

...
In particular, the design is not intrusive and it lets library expose their cmake inside boost or independently.

While non-intrusive design is a good thing for an external add-on, when you can't modify the original, I think boost should strive for a solution, where cmake is an integrated & independent part of each individual library.

We can discuss this also. Cheers, Raffi

2196

Age (days ago)

2200

Last active (days ago)

List overview

Download

38 comments

15 participants

participants (15)

Alexander Grund
Andrey Semashev
Edward Diener
Mateusz Loskot
Mike Dev
mike.dev＠gmx.de
Niall Douglas
Peter Dimov
Raffi Enficiaud
Rene Rivera
Richard
Robert Ramey
Roger Leigh
Stefan Seefeld
Steven Watanabe