Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-30 17:47:33
On 5/30/17 10:00 AM, Niall Douglas via Boost wrote:
>> 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.
I'm not convinced it needs all that to not be "useless". I use it for
generating the IDE. It does a (barely) adequate job on this, but it's
better than trying to maintain the IDE project by hand.
> 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.
This sounds like it would be a worthy project on it's own - perhaps as
part of boost tools. I don't think including in the scope of a
particular library is a great idea. Doing this makes reviewing the
library a much larger effort for everyone involved.
> (well, once all the many bugs are ironed out, it's still pretty immature
> and buggy)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk