On Saturday 20 September 2014 00:26:26 Belcourt, Kenneth wrote:
On Sep 19, 2014, at 12:27 AM, Andrey Semashev
wrote: Kenneth,
dba Noel
Sorry, I took the name from your email address. I've never heard of "dba" before, I suppose its your alias for Boost activity?
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.
Well, now that you're aware of the problem, you can prevent pulling from Boost until implicit-dependency is fixed. And the problem was already released with 1.56, so users who updated are affected. Since there were not many reports I'd assume Boost.Build (or specifically implicit-dependency) is not widely used in users' projects.
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.
Ok, lets's find the difference between the failing and running testers. Do you have access to a running one?
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).
I restored my modularization branch and incorporated the commit from https://github.com/boostorg/mpl/pull/12 just in case so that the work is not lost. If you revert MPL, you can pull from that branch instead of develop to reproduce the failing behavior. Let me know if I should do anything else.