On 1 October 2017 at 18:50, Steven Watanabe via Boost wrote:

Once you have a script for merging the markup files, hooking it into the regression scripts should be trivial.

Not really, I know from experience that maintenance is much, much easier if I run things myself. I also find the regression testing system to be impenetrable - I can't find anything in the source that loads the file in, and the documentation refers to a script that doesn't exist.

On 1 October 2017 at 19:58, Steven Watanabe via Boost wrote:

AMDG

On 10/01/2017 12:35 PM, Daniel James via Boost wrote:

...

On 1 October 2017 at 18:50, Steven Watanabe via Boost wrote:

...

Once you have a script for merging the markup files, hooking it into the regression scripts should be trivial.

Not really, I know from experience that maintenance is much, much easier if I run things myself. I also find the regression testing system to be impenetrable - I can't find anything in the source that loads the file in,

https://github.com/boostorg/regression/blob/develop/reports/src/boost_report...

...

and the documentation refers to a script that doesn't exist.

Meaning build_results_all.sh? Rene apparently moved things around since the last time I looked. After a lot of hunting, I finally found it here https://github.com/boostorg/regression/tree/ci/test-reports

Apart from the complexity of the system, it looks like it doesn't have access to the whole tree, so it would be costly to do it there.

AMDG On 10/01/2017 11:55 AM, Vinnie Falco via Boost wrote:

On Sun, Oct 1, 2017 at 10:10 AM, Daniel James via Boost wrote:

...

I'm looking into implementing a mechanism for updating explicit-failures-markup.xml without updating the super project.

If I could humbly request a feature, I would like a way to indicate in the explicit-failures-markup.xml that my library should not attempt to be compiled on a particular configuration. For example, Beast requires C++11 so it would be nice if 1. No time was wasted attempting to build beast on pre-C++11 environments, and 2. the column in the test matrix is colored or shaded to indicate that it is known to be an unsupported platform.

explicit-failures-markup.xml only affects the reports. It doesn't have any way of affecting what is compiled. You'd need to adjust the test Jamfile for that. (aka config.requires)

For example, Beast cannot compile on msvc-12 or earlier (because no C++11), yet it shows errors in the matrix here: http://www.boost.org/development/tests/master/developer/beast.html

I would like those columns to indicate that it is not a supported platform.

Like this? https://github.com/boostorg/boost/blob/master/status/explicit-failures-marku... In Christ, Steven Watanabe

On 10/1/2017 2:11 PM, Vinnie Falco via Boost wrote:

On Sun, Oct 1, 2017 at 11:02 AM, Steven Watanabe via Boost wrote:

...

Like this? https://github.com/boostorg/boost/blob/master/status/explicit-failures-marku...

I added that for beast months ago:

https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mark...

But it seems to still want to build.

The explicit-failures-markup.xml markup does not affect whether something builds or not. See http://www.boost.org/doc/libs/1_65_1/libs/config/doc/html/boost_config/build... to implement build time configuration so that you can turn off building in your jam file when certain c++11 features are not available.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 1 October 2017 at 19:24, Antony Polukhin via Boost wrote:

2017-10-01 20:10 GMT+03:00 Daniel James via Boost : <...>

...

Does that sound okay?

Sounds awesome! Please, do that ASAP.

But do not use 'status' folder, as we already have 'meta' folder for Boost specific integration files.

Sorry, I meant to say 'meta'.