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:

https://github.com/jeking3/boost-ci

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 graph_parallel. 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 https://github.com/boostorg/logic/issues/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 infrastructure.

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 "unusable".

Thanks,

Jim