Subject: Re: [boost] trunk vs release
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-21 14:56:06
Stefan Seefeld wrote:
> Vladimir Prus wrote:
>> Stefan Seefeld wrote:
>>> Vladimir Prus wrote:
>>>>> I don't quite agree. Assuming I have boost version N installed on my
>>>>> system (no matter by what means), I may want to test a given library
>>>>> (from whatever branch) against the installed system, not necessarily a
>>>>> working copy of a whole boost tree.
>>>> Can you explain why -- as in specific use cases? Especially given the
>>>> lack of source- and binary- compatibility guarantees.
>>> May be that's precisely what I want to test. :-)
>>> Seriously, if I'm working on a boost library, I may want to test against
>>> different versions of boost (requisite libs).
>> Why? I assume not out of mere curiosity, but because you assume some
>> users will use mixed Boost, and then we're back to the question why
>> they might want to do that.
> Let's not get hung up on this particular use-case. Let's just assume
> people want to see (or even validate) whether a particular boost
> component (library) builds against some other (externally managed) boost
I don't like "let's just assume". We can build quite a complicated scheme
that does not solve anybody's problem.
> If you don't like that use-case, here is another one:
> A long time ago, Rene was working on a buildbot setup for boost. I
> suggested that a plausible situation would be that contributors might
> want to help testing boost, but not the entire thing, but only one
> module at a time. They would have a known-good ('golden') build of boost
> somewhere on their system, and a full build&test-cycle would then
> consist in checking out the module, build it, test it, send back results
> to the buildmaster. Quite a reasonably small chunk of work, we thought.
> The whole idea was that this was fine-grained enough such that 1) more
> people would be willing to contribute and 2) the time such a task would
> take would be reasonably small, such that the official build / test
> report would always reflect the current state (or with a very small delay).
I think testing a subset of Boost is orthogonal to mixing different versions.
You can checkout all of Boost, and run tests for select libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk