[build][geometry][regression] Geometry develop regression tests are blank
Hi, 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'm currently running the regression.py myself in hope of finding the cause. I see that in bjam.log the only tests that are dumped are: boost-test(RUN_PYD) "geometry/__boost_check_library__" : "status/boost_check_library.py" boost-test(RUN_PYD) "geometry/extensions/__boost_check_library__" : "status/boost_check_library.py" boost-test(RUN) "geometry/index/varray_old" : "libs/geometry/index/test/varray_old.cpp" boost-test(RUN) "geometry/index/varray" : "libs/geometry/index/test/varray.cpp" boost-test(RUN_PYD) "geometry/index/__boost_check_library__" : "status/boost_check_library.py" varray tests are the only ones that are run at the most top level of Geometry Jamfiles (of sublib geometry/index in this case) with test-suite: https://github.com/boostorg/geometry/blob/develop/index/test/Jamfile.v2#L24 The rest of the tests is run with build-project, also for the main part of the library: https://github.com/boostorg/geometry/blob/develop/test/Jamfile.v2#L26 The varray tests results are shown on the regression page and can be found in bjam.log and in XML file with revision set. The rest of the tests is neither dumped nor has the revision set, however they are run during regression testing so can be found in bjam.log and also in XML file but with empty revision. Adam
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. Should local changes like the one in Compute influence the behavior of bjam in other modules? Could we somehow prevent it from happening in the future? Adam
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
Steven Watanabe Via Boost wrote:
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
On 03/29/2017 01:00 PM, Adam Wulkiewicz via Boost wrote: this test probably shouldn't be reported in the regression output, using compile is not correct in the first place.)
To make sure I understand you correctly are you suggesting replacing `compile` rule with `exe` rule? So change: compile check/has_opencl.cpp : : has_opencl ; into exe has_opencl : check/has_opencl.cpp ; which works, btw. Adam
AMDG On 03/29/2017 03:07 PM, Adam Wulkiewicz via Boost wrote:
Steven Watanabe Via Boost wrote:
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.)
To make sure I understand you correctly are you suggesting replacing `compile` rule with `exe` rule? So change: compile check/has_opencl.cpp : : has_opencl ; into exe has_opencl : check/has_opencl.cpp ; which works, btw.
I suggested obj, not exe (there's no need to link), but that works to. In Christ, Steven Watanabe
Steven Watanabe Via Boost wrote:
On 03/29/2017 03:07 PM, Adam Wulkiewicz via Boost wrote:
Steven Watanabe Via Boost wrote:
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.)
To make sure I understand you correctly are you suggesting replacing `compile` rule with `exe` rule? So change: compile check/has_opencl.cpp : : has_opencl ; into exe has_opencl : check/has_opencl.cpp ; which works, btw.
I suggested obj, not exe (there's no need to link), but that works to.
Thanks, I can suggest a fix now. Adam
participants (2)
-
Adam Wulkiewicz -
Steven Watanabe