Re: [boost] [cmake] Minimum viable cmakeification for Boost

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-21 12:05:30

On 21/06/2017 09:01, Thomas Heller via Boost wrote:
> On 06/20/2017 11:56 PM, Niall Douglas via Boost wrote:
>> The cmake docs are updated on a git pull request basis by volunteers as
>> and when someone feels they need to be updated. They are, in general,
>> woefully out of date. And as I mentioned here before, Stephen never
>> finished the cmake3 documentation effort he began due to changes in
>> personal circumstance (returning home to Ireland).
> 
> To be honest, and forgive my skepticism, I find this to be not a good
> sign of something that is to suppose to dominate the industry:
>  - There is no real documentation available on the "best practices" you
>    advertise, they are told based on anecdotes
>  - Kitware is indeed a company who offers support and consulting and
>    claims to maintain CMake.
> 
> Not saying that you (or Stephen Kelly) don't know what you are talking
> about...

Kitware makes no money from cmake. For them it's a cost of sales. They
support it only in so far as cmake provides build for their money making
products. cmake was always something they just open sourced to enable
the clients of their paid products buy in to their custom build process
without worrying about getting locked in.

Most of the docs and features come from open source contribution as
submitted patchsets. They vary enormously in quality, Kitware only
provides minimum review before merging. Like with most open source build
systems, there is a huge open bug count, many serious bugs unfixed in
eight or more years.

Nobody has ever claimed cmake is great, or even good. Nobody I know who
uses it likes it or thinks it well designed. It's only major claim is
that it isn't flawed with a showstopper failing like say scons or make,
and it lets average devs use their preferred local IDE.

But it has won the great build systems competition. It is the industry
standard, nothing else is remotely close in market share. And that
brings lots of ecosystem benefits which less popular build tools cannot
achieve. There is very good reason that VS2017 can now directly load and
work with cmake projects. Every other major IDE can, so Visual Studio
had to keep up. That speaks volumes as to where the industry is going.

>> In the cmake I mocked up we are separating concerns: "how to build this
>> library" from "how to configure this library". It is like the intended
>> difference between the SConstruct and SConscript files in scons: one
>> file says what needs to be built and how they relate declaratively, the
>> other file sets flags, optimisation, settings according to the target
>> system etc imperatively.
> 
> I can see that and certainly see the benefit of it. I think there is a
> great chance to further drive the modularization with that approach. I
> guess the consensus would be (each of those file local to the module
> being built):
>  - CMakeLists.txt: Describe targets declaratively
>  - Dependencies.cmake: Describe dependencies (PUBLIC, PRIVATE,
>    INTERFACE)
>  - Install.cmake: Define the install logic
>  - Setup.cmake: Define Options etc. and eventually call
>    add_subdirectory to have the CMakeLists.txt being processed

One very nice approach which I'd personally prefer, but felt it too
risque to propose here, is that CMakeLists.txt is always auto generated
and library devs cannot customise it. They can customise .cmake files in
a cmake directory very similarly to what you just listed, but you are
only permitted to use a certain whitelist of cmake commands in certain
files, so for example the cmake/targets.cmake file solely allows
declarative targets and no logic. Other files very like the above do
stuff exactly like you suggest like install, setup etc.

This forces library devs to write clean, scalable, reusable cmake. But I
know boost-dev doesn't like their code being enforced via automated
rules, and I think it would count as "cmake innovation", so I didn't
propose that here.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/