Modularizing explicit-failures-markup.xml
Hi, I'm looking into implementing a mechanism for updating explicit-failures-markup.xml without updating the super project. My basic idea is that modules can have a 'status/explicit-failures-markup.xml' file, and I'll write a script to update the super project file from modules. It will have the same format as the super project file, so can just copy and paste the relevant parts into your module. Does that sound okay? It might be better if the regression scripts handled this themselves, but I'm not sure if anyone would be available to implement that. Daniel
AMDG On 10/01/2017 11: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. My basic idea is that modules can have a 'status/explicit-failures-markup.xml' file, and I'll write a script to update the super project file from modules. It will have the same format as the super project file, so can just copy and paste the relevant parts into your module.
Does that sound okay? It might be better if the regression scripts handled this themselves, but I'm not sure if anyone would be available to implement that.
Once you have a script for merging the markup files, hooking it into the regression scripts should be trivial. Alternately, the code that actually loads explicit-failure-markup.xml should be safe to use with multiple files (It's just a matter of tracking them all down). In Christ, Steven Watanabe
On 1 October 2017 at 18:50, Steven Watanabe via Boost <boost@lists.boost.org> 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.
AMDG On 10/01/2017 12:35 PM, Daniel James via Boost wrote:
On 1 October 2017 at 18:50, Steven Watanabe via Boost <boost@lists.boost.org> 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 In Christ, Steven Watanabe
On 1 October 2017 at 19:58, Steven Watanabe via Boost <boost@lists.boost.org> 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 <boost@lists.boost.org> 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.
On Sun, Oct 1, 2017 at 10:10 AM, Daniel James via Boost <boost@lists.boost.org> 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. 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. Thanks
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 <boost@lists.boost.org> 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 Sun, Oct 1, 2017 at 11:02 AM, Steven Watanabe via Boost <boost@lists.boost.org> 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-markup.xml#L353> But it seems to still want to build.
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 <boost@lists.boost.org> 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-markup.xml#L353>
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 <boost@lists.boost.org> wrote:
2017-10-01 20:10 GMT+03:00 Daniel James via Boost <boost@lists.boost.org>: <...>
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'.
On 1 October 2017 at 18:10, Daniel James <dnljms@gmail.com> wrote:
I'm looking into implementing a mechanism for updating explicit-failures-markup.xml without updating the super project. My basic idea is that modules can have a 'status/explicit-failures-markup.xml' file, and I'll write a script to update the super project file from modules. It will have the same format as the super project file, so can just copy and paste the relevant parts into your module.
This is running now, you can see an example at: https://github.com/boostorg/functional/blob/develop/meta/explicit-failures-m... That file doesn't validate using the existing schema as it doesn't have any 'mark-toolset' or 'note' elements, I think it should be pretty trivial to make them optional, so I'll try to do that soon, or maybe there should be a separate schema for modules?
Boost - Dev mailing list wrote
[...] Does that sound okay? It might be better if the regression scripts handled this themselves, but I'm not sure if anyone would be available to implement that.
Daniel
This is great (with the caveat that it should be in meta/, not status/, as mentioned elsewhere)! Thanks for doing this! Louis -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
participants (6)
-
Antony Polukhin -
Daniel James -
Edward Diener -
Louis Dionne -
Steven Watanabe -
Vinnie Falco