Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-30 17:00:18

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