Subject: Re: [boost] CMT Library and CI Status for Boost 1.68.0
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-06-27 20:33:43
On 6/27/2018 3:29 PM, James E. King III via Boost wrote:
> I have been working on adding CI to the CMT libraries (and a few others).
> This provides improved quality and metrics for each repository with builds
> for various linux and windows combinations, as well as code coverage and
> static code analysis with coverity scan. Here is the current status for
> work that will make it into 1.68.0:
> The CI framework I have been adding is here:
> CI has been enabled on the following repositories (and any identified
> defects have been resolved) and is passing:
> function, mpl, pool, property_map, ptr_container, rational, tokenizer
> In addition, Boost.Move and Boost.Signals2 are also now using this
> framework to improve deliverable quality.
> CI not yet enabled on (and reasons):
> Boost.Assign fails to compile <https://github.com/boostorg/assign/pull/16>
> with MSVC 2012 in Appveyor.
> Boost.ConceptCheck fails to compile
> <https://github.com/boostorg/concept_check/pull/13> on most compilers in
> Travis CI and Appveyor. (It looks like it's unusable.)
> Boost.DisjointSets - status unknown (no CI) - open question still
> unanswered: Can we merge this into container? It is only used by graph and
> Boost.DynamicBitset fails to compile
> <https://github.com/boostorg/dynamic_bitset/pull/23> on all MSVC and on
> linux with c++03 mode.
> Boost.Interval (numeric/interval) fails to compile
> <https://github.com/boostorg/interval/pull/14> - most combinations fail and
> may go into an infinite loop in some cases.
> Boost.Logic (tribool) uncovered issue #8
> Boost.Signals - we discussed a removal notification in an upcoming release
> but no action has been taken by the CMT yet to make this happen so it may
> slip into the next release.
> Boost.Statechart needs some Jamfile help to get it to work with this CI
> I am most concerned about Boost.ConceptCheck and Boost.Interval. Both may
> be unusable at this point. If folks have any spare cycles and care to take
> a look, it would be appreciated.
Thanks for all your work.
Still it is a bit dramatic to declare a library "unusable" because it
fails one or more tests with specific compiler setups. I think it is
enough just to say that certain libraries have some problems which we
should try to solve. That this may happen does not make a library
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk