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

On Sep 15, 2014, at 9:53 AM, Andrey Semashev wrote:

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.

Finally had some time to take a closer look at this. So I was wrong, the Sandia develop Linux testers do remove the previous boost install meaning it correctly installs all the headers on those testers. This means that the implicit dependency rule works okay on Linux, and also means that it’s broken somehow on Darwin, QNX, and Windows (except for the newer gcc-mingw versions). So I think your changes that we pushed are actually okay, and we seem to have exposed a Boost Build problem with the implicit dependency rule. <implicit-dependency>/boost//headers We may need help from BB guys to track this down.