On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev@gmail.com> 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? — Noel