Re: [boost] [cmake] Pull request announcement

Subject: Re: [boost] [cmake] Pull request announcement
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-09-14 17:55:14

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