On Sep 13, 2014, at 4:06 PM, Andrey Semashev
On Saturday 13 September 2014 21:25:58 Belcourt, Kenneth wrote:
On Sep 13, 2014, at 3:11 PM, Andrey Semashev
wrote: 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.
It is possible that this never worked before, not in complicated cases like MPL anyway. At some point someone ran 'b2 headers' or something similar on the test machine, and it worked while the headers layout in submodules was more or less stable.
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything. So I think we need to revert the MPL change unless we can figure out how to fix it. I agree there’s a workaround by installing all the headers with ‘b2 headers' but we broke major functionality in b2 with this commit, yikes! — Noel