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

Subject: Re: [boost] [EXTERNAL] [mpl] [build] [testing] Merge pull requests
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2014-09-19 20:26:26

On Sep 19, 2014, at 12:27 AM, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> On Friday 19 September 2014 03:54:47 Belcourt, Kenneth wrote:
>> On Sep 17, 2014, at 12:39 PM, Andrey Semashev <andrey.semashev_at_[hidden]> 
> wrote:
>>> There were a lot of discussions about MPL recently, and I created a few
>>> pull
>>> requests to address issues:
>>> 
>>> https://github.com/boostorg/boost/pull/39
>>> 
>>> 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.
>>> 
>> I’d like to revert the MPL PR that caused our testing problems, and the one
>> Edward just applied.  It was wrong of me to commit the PR without any
>> testing.  There’s been some list discussion but my overall concern is that
>> we can’t clearly explain why some develop testers are broken and others are
>> working okay.  The commit completely broke Darwin, Debian, FreeBSD, QNX and
>> Windows.  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.
>> 
>> While we could apply Andrey’s PR (below) I’m afraid that may mask real
>> underlying problems that we may not find out about until this hits master,
>> or worse, users.  I’ll work with Andrey to get the MPL changes applied,
>> perhaps in smaller PRs.
>> 
>> Please let me know if you have concerns.
> 
> Kenneth,

dba Noel

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

We’re in agreement that implicit-dependency is broken for some reason.  But note that several of our internal projects utilize BB implicit-dependency and it works fine for us.  My concern is that these projects will break when they pull Boost with this change, and this may well happen to other users.

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

Yes, but be aware that it’s not just tools, every invocation of b2 is broken, fails to install full set of headers.

> That's what my second PR achieves, and I think this is the correct 
> fix. Did you try it?

Yes, it works on Linux, but I’m still reluctant to apply it without a firm understanding why the random tester behavior is occurring.  I’m sort of okay with wholesale failure but I’m not okay with some RHEL and Ubuntu testers working okay, others failing.

> The problem with implicit-dependency should be investigated too, and Vladimir 
> indicated in the PR that he wants to do that.

Yes, saw that.

> You can revert MPL if you still want to, but I honestly don't know how else 
> (on the MPL side) we can do this.

I guess that’s really the question I plan to investigate (while the develop testers are all working correctly).