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/