On Sep 13, 2014, at 3:11 PM, Andrey Semashev
On Saturday 13 September 2014 20:46:40 Belcourt, Kenneth wrote:
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.
So, to be clear, with explicit 'b2 headers' it compiles as expected?
Yes.
This is the source of the nightly testing problem, the run script doesn’t
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.
I suppose, the expectation is that b2 will infer the dependent headers from the compiled sources somehow and installs them. It's possible that it is not able to pass through the preprocessor magic used in MPL. I think there was a discussion some time ago about some headers not being automatically installed this way. Although that doesn't explain why only some testers were broken.
It’s because I don’t remove the existing boost directory so it’s already fully (correctly) populated. These testers will also fail if I remove their boost directories.
Anyway, IMHO, 'b2 headers' should be explicitly invoked by the testing scripts.
Right, testers would be okay with that though I think a breaking change like this needs a bit more visibility so that testers, developers, and others, understand this change. — Noel