Re: [boost] [EXTERNAL] [testing] mpl/core tests not visible

Subject: Re: [boost] [EXTERNAL] [testing] mpl/core tests not visible
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-09-15 11:17:50

On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
> On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev_at_[hidden]> 
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.

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.