Subject: Re: [boost] Master Regression Tests Failing
From: Tom Kent (lists_at_[hidden])
Date: 2017-10-09 23:26:07
On Mon, Oct 9, 2017 at 6:15 PM, Edward Diener via Boost <
> On 10/9/2017 7:09 PM, Robert Ramey via Boost wrote:
>> On 10/9/17 3:20 PM, Tom Kent via Boost wrote:
>>> On Mon, Oct 9, 2017 at 10:45 AM, Peter Dimov via Boost < Can we back out
>>> this change until we can figure out a way to do it where it
>>> doesn't break our regression suite?
>>> I don't believe there is a way to specify that the master tests use the
>>> master version of build, If I recall, a long time ago, we decided to use
>>> separate version of build for the regression tests, instead of the one
>>> from the superproject? Is this just the head of develop? Does anyone
>>> remember the rationale for this?
>> Cant we just use the master version of boost build for ALL the testing -
>> master and develop branch? Does it make sense to use an experimental
>> version of the test tools to test anything?
> Am I the only one who thinks it logical that a regression test for
> 'master' should use the 'master' branch of everything and the regression
> test for 'develop' should use the 'develop' branch of everything ? Why is
> this even going to be debated ? I have no idea why the 'master' branch uses
> the 'devlop' branch of Boost Build, but that does not seem like it can ever
> be right.
To be fair, I believe the failure wasn't in building boost but in building
the jam log processor, so it does make sense to disconnect that from the
I really feel like we've had this conversation before, and there was a good
reason to set it up like this. Unfortunately I can't find the chain on
Regardless, it seems like having the defaults in boost build be something
that depends on a specific feature in boost is too aggressive. Would it be
possible to put this feature on some kind of flag (default off) until the
features it depends on have been in master for a while? Is this something
that could hit other users of boost build who may be using it for non-boost