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

Subject: Re: [boost] [EXTERNAL] [testing] mpl/core tests not visible
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2014-09-15 11:30:26

On Sep 15, 2014, at 9:17 AM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> 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.

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.