I naively assumed that the Outcome CMakeLists.txt was a straightforward, self-contained affair. After all, how complicated does it need to be for a library that provides 3 similar classes and a handful of tests? I was wrong...
Such a cmake would be useless for production code. You need support for all the sanitisers and static analysis tooling; building and testing libraries in header-only, static and dynamic lib forms, C++ Module and non-module forms, and with C++ exceptions enabled or disabled; CTest scripting for Travis and Appveyor CI; CPack packaging of prebuilt binaries; documentation generation with testing of example snippet code; CDash upload of CI test outputs and build artifacts; tracking and maintenance of git submodule dependencies; permuting ABI for unstable libraries - and all that is still a subset of what the common cmake infrastructure provides for all libraries which use it. Any reasonably mature production ready cmake project ends up implementing its own edition of those sorts of features, thus duplicating work and maintenance. The common cmake infrastructure provides it for any client library based on filled in parameters. You just fill in the parameters and voila, no more work, bye bye thinking about the build or CI or test stuff when you make a new C++ library. (well, once all the many bugs are ironed out, it's still pretty immature and buggy) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/