Subject: Re: [boost] [EXTERNAL] [testing] mpl/core tests not visible
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2014-09-13 16:46:40
On Sep 13, 2014, at 1:39 PM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Sat, Sep 13, 2014 at 9:30 PM, Belcourt, Kenneth <kbelco_at_[hidden]> wrote:
>> On Sep 12, 2014, at 11:39 PM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
>>> Do we need to regenerate the preprocessed headers?
>>> We shouldn't be, the file is there:
>>> The only thing that is needed is 'b2 headers'. I also deleted the boost
>>> directory prior to it, but it may not be required.
>> Tried this, didnt help.
> Multiple other testers are running fine, including Sandia gcc, so I
> think this is something specific for this particular tester. Do you
> have access to the testing machine? What is the result and output of
> the 'b2 headers' command? The correct result (the one I'm having) is
> that boost/mpl is a normal directory, and all files, including
> arg.hpp, are links to the files in libs/mpl and libs/mpl/core.
> Also, could you check that Jamroot is the latest?
Looks like a change in how b2 runs. IIRC, running b2, without specifying the headers target, would look for the boost directory and, if not found, would run the headers target, and then proceed with the build. It now seems that if b2 is run (no boost directory and no header target specified on the command line), only about 250 files are installed into the boost directory, and then b2 starts compiling code. An explicit 'b2 headers' installs over 1300 headers.
This is the source of the nightly testing problem, the run script doesnt explicitly invoke b2 headers, it first builds b2 then proceeds to build process_jam_log resulting in a subset of headers being installed and process_jam_log.cpp failing to compile due to missing headers.
Most / all non-Linux develop testers have stopped cycling so it seems we need to get this fixed ASAP. One possible resolution is to not try to figure out the change in b2 behavior and fix the nightly testing to explicitly invoke b2 headers. I suspect that would get the testers cycling again. Not sure how users might feel about the change in b2 behavior though.