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

Subject: Re: [boost] [EXTERNAL] [mpl] [build] [testing] Merge pull requests
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-11-12 08:50:39

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.