AMDG On 03/29/2017 01:00 PM, Adam Wulkiewicz via Boost wrote:
Adam Wulkiewicz wrote:
Boost.Geometry develop tests (http://www.boost.org/development/tests/develop/developer/geometry.html) stopped showing around 22.03. The first blank run (teeks99-03-dc3.9-1z-Docker-64on64) is from Wed, 22 Mar 2017 01:20:13. Do you have an idea what may be the cause? I see that many changes in Build and Regression was done around 22.03. Geometry was also modified that day but the first commit is from 12:40+1 so later than the first blank run.
I checked the XML of one of them (teeks99-09-n-win2012R2-64on64) and it seems that the revision attribute of <test-log> tag is not set for the most of the tests.
I localized the problematic change in Boost.Compute: https://github.com/boostorg/compute/pull/689/files
If you want to reproduce it checkout master and develop branches of Boost.Compute and try to run the tests from BOOST_ROOT/status passing --dump-tests: cd status b2 --dump-tests
You should see lists of tests and with develop some number of tests are missing (from Detail, Geometry, Hash, Math, Multiprecision, Odeint, Parameter), also one entry from Config: boost-test(RUN) "config/link_test_test" : "libs/config/test/link/main.cpp"
I'm not sure how this should be fixed, besides commenting out lines in Compute's Jamfile, so I'm unable to create a PR.
Changing 'compile' to use an 'obj' target instead should fix it. There's a bug with --dump-tests when a test target is used in a configure check. (Note that since this test probably shouldn't be reported in the regression output, using compile is not correct in the first place.)
Should local changes like the one in Compute influence the behavior of bjam in other modules?
The only thing that's affected is dump-tests. The reason is that --dump-tests is handled prematurely, before all the test targets have been generated.
Could we somehow prevent it from happening in the future?
In Christ, Steven Watanabe