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
> 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
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  support, which is Stefan's
responsibility to maintain for GIL.
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".
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk