Re: [boost] [EXTERNAL] [mpl] [build] [testing] Merge pull requests

Subject: Re: [boost] [EXTERNAL] [mpl] [build] [testing] Merge pull requests
From: Suckow, Thomas J (Thomas.Suckow_at_[hidden])
Date: 2014-09-19 11:56:26

>> > 
>> > Invoke 'headers' target before building testing tools. Note that
>>several
>> > testers are currently failing to run because of this problem. Since
>>this
>> > affects the testing process, I'd appreciate if someone familiar with
>>it
>> > could take a look.
>> >

>> 
>>But what¹s really worrying is that some RHEL testers are still
>> merrily cycling while other RHEL testers are broken.  Same for Ubuntu,
>>some
>> are cycling okay while some are broken.  I think it¹s too risky to
>>apply a
>> patch when we, honestly I, don¹t understand why this is happening.

Would a bjam.log from a failing RHEL machine help?

There is everything from:
../libs/multiprecision/test/test_rat_float_interconv.cpp:195: error: '>>'
should be '> >' within a nested template argument list

To:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/s
hared_ptr.h:146: error: cannot use typeid with -fno-rtti

It takes 12min for my build to fail, I could up the build once an hour if
that might help. I could even auto upload the bjam.log to the regression
ftp.

>Kenneth, I've already explained why the problem has likely appeared, and
>moving back to the monolithic MPL is what covers it. It's not the fix.

If we want to continue down this route, I would rather fix it than revert
it. It is the develop branch, things break, they get fixed.

>I admit I don't know why implicit-dependency doesn't work in the tools
>Jamfile, but it is clear that the intention was to invoke 'headers' prior
>to 
>building. That's what my second PR achieves, and I think this is the
>correct 
>fix. Did you try it?
>
>The problem with implicit-dependency should be investigated too, and
>Vladimir 
>indicated in the PR that he wants to do that.

I had brought up the issue with the headers target in the past on the
boost-build list.

For it to work for me I use:
<use>/boost//headers
                   
                   
                   
          
<implicit-dependency>/boost//headers

This was a breaking change in 1.56 for our codebase as before we simply
included the /boost//headers target. If this is the intended behavior of
use and implicit-dependancy I think it is possible to make the headers
target an alias that has a usage-requirement of the use and
implicit-dependancy of the real headers target. This would make the
headers target behave like it did before 1.56. There seemed to be little
interest when I brought it up before, I think I was the only one affected
at the time.

-
Thomas