[cmake] Pull request announcement

classic Classic list List threaded Threaded
98 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[cmake] Pull request announcement

Boost - Dev mailing list
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::<library_name> (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::<library_name>
        - 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::<library_name>

- 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





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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
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.



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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
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.



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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Sep 14, 2018 at 2:44 PM, Mike Dev via Boost
<[hidden email]> 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.

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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...
     


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
On Fri, Sep 14, 2018 at 10:40 AM Roger Leigh via Boost <
[hidden email]> 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

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Mike Dev wrote:

> - STATIC for regular libraries

Why not look at "BUILD_SHARED_LIBS"?

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> 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

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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> 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

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

[cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> 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.

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.

> 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,
 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




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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Niall Douglas
> Sent: Friday, September 14, 2018 6:00 PM
> Cc: Niall Douglas <[hidden email]>
> 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


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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/dependencies.cmake
https://github.com/pdimov/boost-cmake-demo/blob/master/libs/system/cmake/default.cmake#L41-L53 
(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.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 14 Sep 2018 at 18:14, Niall Douglas via Boost
<[hidden email]> 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

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

[cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Peter Dimov
> via Boost
> Sent: Friday, September 14, 2018 6:25 PM
> To: [hidden email]
> Cc: Peter Dimov <[hidden email]>
> 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


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
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.


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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...
     


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

Re: [cmake] Pull request announcement

Boost - Dev mailing list
On Fri, 14 Sep 2018 at 19:42, Stefan Seefeld via Boost
<[hidden email]> 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

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