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

Subject: Re: [boost] [cmake] Minimum viable cmakeification for Boost
From: paul (pfultz2_at_[hidden])
Date: 2017-06-20 23:13:24

On Tue, 2017-06-20 at 22:56 +0100, Niall Douglas via Boost wrote:
> > 
> > I'll ask again: do you have any reference to those statements? The
> > official cmake docs seem to disagree about this specific case.
> 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).
> 
> > 
> > Why should the root cmake be responsible for configuring a specific sub
> > module. This is asking for cluttering everything into one single entity
> > in a (almost) totally unrelated place. Why not keep it local to where it
> > should be used.
> I'll repeat myself yet again, but to be honest it'll be for the last
> time as I really don't care about this enough to spend more time
> repeating myself. I have other stuff to be doing than repeating myself
> (specifically, Outcome v2).

We are not asking to repeat yourself, we are asking for references. As the
references I have for best practices and modern cmake from both Daniel Pfeifer
and Stephen Kelley do not align with what you are saying:

https://www.slideshare.net/DanielPfeifer1/cmake-48475415

http://www.steveire.com/WhatWhyHowCMake.pdf

https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_f
riday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf

Nor does the boost cmake repo they put together align with what you are saying
either:

https://github.com/steveire/BoostCMake

https://github.com/boost-cmake/boost-cmake

> 
> 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.
> 
> In exactly the same way as with scons, the non-root CMakeLists are the
> declarative structure describing a build graph. The rootmost CMakeLists
> are the imperative commands transforming some subset of that build graph
> into a build according to local conditions.

Yes, the build scripts should be more declarative, but projects should be
standalone as well, and not require a root cmake. Of course, my approach to
the boost-cmake is fairly declaritive, there is only one conditional in the
top-level cmake, whereas your cmake code is much less delcarative with a lot
of conditionals all over.Â