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

Subject: Re: [boost] [EXTERNAL] [mpl] [build] [testing] Merge pull requests
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2014-11-12 09:04:17

On 11/12/2014 04:50 PM, Edward Diener wrote:
> On 11/12/2014 8:39 AM, Andrey Semashev wrote:
>> On Wed, Nov 12, 2014 at 4:10 PM, Edward Diener <eldiener_at_[hidden]> wrote:
>>> On 11/12/2014 2:41 AM, Andrey Semashev wrote:
>>>>
>>>> On Sat, Sep 20, 2014 at 4:11 AM, Belcourt, Kenneth <kbelco_at_[hidden]>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Sep 18, 2014, at 11:25 PM, Edward Diener <eldiener_at_[hidden]>
>>>>> wrote:
>>>>>
>>>>>> On 9/18/2014 11:54 PM, 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:
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> Is not the pull request just in the developer branch ? In that case you
>>>>>> could leave the pull request as is and try to solve it without affecting the
>>>>>> master branch at all.
>>>>>
>>>>>
>>>>> I’d prefer to revert and ensure all develop testers come back online.
>>>>> Then can we work on figuring out how to apply these changes and test them to
>>>>> ensure no breakage *before* we push them into develop.
>>>>
>>>>
>>>> Are there any news about this? Is someone looking into the problem
>>>> with Boost.Build?
>>>
>>>
>>> For mpl and 'develop' the latest commits that I see are pull requests from
>>> Eric Niebler which I merged. I do not believe these have caused any
>>> underlying problems.
>>
>> Sorry, the context is probably lost.
>>
>> When my pull request that separated MPL into MPL.Core was merged, it
>> broke some testers. The breakage was caused by Boost.Build behavior,
>> which did not create links to all headers in MPL and MPL.Core. The
>> relevant threads are:
>>
>> http://thread.gmane.org/gmane.comp.lib.boost.devel/254291/
>> http://thread.gmane.org/gmane.comp.lib.boost.devel/254629/
>>
>> It is not clear why that happens but I created a pull request with a workaround:
>>
>> https://github.com/boostorg/boost/pull/39
>>
>> However, the commit to MPL was reverted and the workaround was not applied.
>>
>> I was asking about the state of the issue with Boost.Build.
>
> Maybe posting on the Boost Build mailing list would help since your pull request with a workaround refers to Boost Build.

If I recall correctly, it was never determined what the breakage is, and how to reproduce it at will.

Is there a reproduction recipe now?

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com