On Mon, Oct 9, 2017 at 6:15 PM, Edward Diener via Boost < boost@lists.boost.org> wrote:
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 a separate version of build for the regression tests, instead of the one tied 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 boost->build relationship. 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 that. 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 builds? Tom