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
wrote: On 11/12/2014 2:41 AM, Andrey Semashev wrote:
On Sat, Sep 20, 2014 at 4:11 AM, Belcourt, Kenneth
wrote: On Sep 18, 2014, at 11:25 PM, Edward Diener
wrote: On 9/18/2014 11:54 PM, Belcourt, Kenneth wrote: > > > On Sep 17, 2014, at 12:39 PM, Andrey Semashev >
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