[boost] [cmake] Pull request announcement

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