On Sep 15, 2014, at 9:17 AM, Andrey Semashev
On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
On Sep 14, 2014, at 1:46 AM, Andrey Semashev
wrote: On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
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.
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
Yes, that does sound like the issue. So, what do you think we should do about it?
As I suggested in another reply, I think we should add 'b2 headers' to the testing scripts as a hotfix. I'd create a pull request, but I have no idea how the testing works and where this command should be added.
I‘m not in favor of a workaround, we need to fix this so the missing MPL headers are all installed.
The long term fix is probably figure out why the headers target is not built first before process_jam_log (I described my theory in another reply) and fix it. This will probably require attention of the Boost.Build team.
So the header target is being built, it just installs significantly less than the full set of MPL headers. You can replicate this by: 0) rm -f bin* boost 1) cd tools/regression/build 2) b2 -q 3) notice that this directory is missing: boost/mpl/aux_/preprocessed If we can get boost/mpl/aux_/preprocessed installed, I think that’s the preferable fix.