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