Re: [boost] [build][compute] Various libraries regression tests missing after change in Compute

Subject: Re: [boost] [build][compute] Various libraries regression tests missing after change in Compute
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2017-03-29 19:15:29

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