On Monday 15 September 2014 15:30:26 Belcourt, Kenneth wrote:
On Sep 15, 2014, at 9:17 AM, Andrey Semashev
wrote: On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
On Sep 14, 2014, at 1:46 AM, Andrey Semashev
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.
You sounded like we needed a solution ASAP. This is the quickest way to fix it that I know.
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.
I'm not a Boost.Build expert, but since 'b2 headers' does the right thing and building the regression tools does not, I'd say that headers target is not invoked in the second case.
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.
I'll try a few experiments with Boost.Build to see if I can invoke the headers target prior to the testing tools.