Modularizing explicit-failures-markup.xml

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Oct 1, 2017 at 10:10 AM, Daniel James via Boost
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
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
> <[hidden email]> 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-markup.xml#L43

In Christ,
Steven Watanabe


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
On Sun, Oct 1, 2017 at 11:02 AM, Steven Watanabe via Boost
<[hidden email]> wrote:
> Like this?
> https://github.com/boostorg/boost/blob/master/status/explicit-failures-markup.xml#L43

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
2017-10-01 20:10 GMT+03:00 Daniel James via Boost <[hidden email]>:
<...>
> 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.

--
Best regards,
Antony Polukhin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
On 1 October 2017 at 19:24, Antony Polukhin via Boost
<[hidden email]> wrote:
> 2017-10-01 20:10 GMT+03:00 Daniel James via Boost <[hidden email]>:
> <...>
>> 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'.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1 October 2017 at 18:50, Steven Watanabe via Boost
<[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
AMDG

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

> On 1 October 2017 at 18:50, Steven Watanabe via Boost
> <[hidden email]> 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.cpp#L78

> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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
> <[hidden email]> wrote:
>> Like this?
>> https://github.com/boostorg/boost/blob/master/status/explicit-failures-markup.xml#L43
>
> 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_config.html 
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
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1 October 2017 at 19:58, Steven Watanabe via Boost
<[hidden email]> 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
>> <[hidden email]> 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.cpp#L78
>
>> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 1 October 2017 at 18:10, Daniel James <[hidden email]> 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-markup.xml

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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

[SPAM] Re: Modularizing explicit-failures-markup.xml

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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

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