|
Boost : |
Subject: Re: [boost] Boost.test failures in develop
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-07 19:16:11
Le 05/10/15 22:43, Robert Ramey a écrit :
>>> c) I have my whole boost development tree to set to master branch so I'm
>>> testing against the next release. Only the serialization submodule is
>>> set to develop (or a feature branch).
>>
>> Unfortunately this is not the way test runners operate
>
> LOL - That's my point exactly. And it is one of the sources of these
> problems. If things were run the way I suggest, you could make a
> temporary mistake in development of Boost.Test which wouldn't ripple
> though to all the libraries which use it for development testing. It
> would make your life a lot easier.
This is also what I suggested (I believe), and something we can envision:
- cloning out full boost
- checking out a particular branch (say "next") of eg. boost.test
- running the runner with the source in place (using the --have-source
switch)
This builds will be triggered only by changes to boost.test[next], so
that it will be boost.all against boost.test[next]. This will add
several columns to the test dashboard.
I think for libraries having a lot of children in the dependency graph,
this would be very beneficial.
> It makes no economic sense to go back and re-write working code to just
> because there is a new standard. There is no benefit unless one want's
> to add features. Some might say that it makes maintenance easier - but
> this is a decision that only a the library maintainer is qualified to make.
In this very case, the changes were also adding features.
Best,
Raffi
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk