Subject: Re: [boost] [EXTERNAL] [testing] mpl/core tests not visible
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-09-15 11:53:39
On Monday 15 September 2014 15:30:26 Belcourt, Kenneth wrote:
> On Sep 15, 2014, at 9:17 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
> > 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]>
> >>> 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.