[boost] [cmake] Pull request announcement

Subject: [boost] [cmake] Pull request announcement
From: mike.dev_at_[hidden]
Date: 2018-09-14 16:14:11

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> 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