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 13:02:14

On 9/19/14, 9:22 AM, "Andrey Semashev" <andrey.semashev_at_[hidden]> wrote:

>On Friday 19 September 2014 15:56:26 Suckow, Thomas J wrote:
>> 
>> 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.
>
>This sounds like the build actually starts (i.e. the testing tools are
>built 
>successfully and library tests began running, some of them failing). This
>is 
>not the problem we're seeing, but it would be interesting to know why it
>doesn't manifest in your case.
>
>Did you somehow modify your build scripts? Do you manually invoke 'b2
>headers' 
>before starting tests? Do you delete the boost directory before running
>tests? 
>Is there anything special in your user-config.jam? How do you start tests?
>
>There's clearly some difference between testers, which makes some of them
>fail 
>and others succeed.

Opps. In my haste I pulled the bjam.log from the last SUCCESSFUL build.
Bjam.log is not built.

I tee¹d the run.py and have uploaded it below
https://gist.github.com/thomassuckow/51f3dc348f9654abfb52

>
>> 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.
>
>I'm not a Boost.Build expert so I didn't quite understand your way of
>fixing 
>it. Could you specify how and what code you changed (i.e. a patch or
>modified 
>code sample)?

When I build our project with boost-build we have to specify headers like
this to make sure the symlinks are made:

exe myExe :
    myExe.cpp
    /boost//program_options
    /boost//system
    :
    <use>/boost//headers
    <implicit-dependency>/boost//headers
    ;

We used to, before 1.56, be able to do:

exe myExe :
myExe.cpp
/boost//program_options
/boost//system
/boost//headers
;

I¹ll go try the alias trick I thought of and see if that would work.

-Thomas