Boost logo

Boost :

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-12-26 10:07:24

On 12/25/2012 12:54 PM, Daniel Pfeifer wrote:
> 2012/12/25 Rene Rivera <grafikrobot_at_[hidden]>
>> On 12/17/2012 12:25 PM, Dave Abrahams wrote:
>>> on Sun Dec 16 2012, Rene Rivera <> wrote:
>>> On Wed, Dec 12, 2012 at 9:49 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
>>>> On Tue, Dec 11, 2012 at 10:52 AM, Rene Rivera <grafikrobot_at_[hidden]>
>>>>> wrote:
>>>>> Hm.. That's barely a step :-\ ..And there's no need to branch. The
>>>> tools
>>>> already support multiple transport methods so we can just add another.
>>>> Which brings me to one of the transport methods regression testing
>>>> currently supports.. Downloading the current trunk/release as a ZIP
>>>> archive. I was hoping to use the github facility that exists for
>>>> downloading ZIPs of the repos. But unfortunately I couldn't make it
>>>> attached the contents of the indirect references to the library
>>>> subrepos.
>>> That's right, unfortunately. However, we can get the exact URLs of the
>>> ZIP files from the GitHub API. I've recently done some scripting with
>>> that,
>>> e.g.**ryppl/blob/develop/scripts/**
>>> In fact, I think someone has coded up what's needed to make a monolithic
>>> zip here:
>>> 9fe2fc2cad9bd2e7e1a38d7e5d4aaa**02fb2b4aea<>
>> After looking at both of those I see no point in using the github api (or
>> additional structure data from sublime -- not totally sure where the
>> submodule info comes from in this case though) for this as it provides no
>> additional information than one can get from just parsing the ".gitmodules"
>> file.
>> Hence the complexity of supporting testing with ZIPs is now a
>>>> magnitude larger as it means dealing with fetching more than a hundred
>>>> individual repos :-(
>> Which now seems the only choice. At the tester side I will have to get the
>> boost-master archive. Then parse out the ".gitmodules" file. And get each
>> subrepo archive individually. Which increases the likelihood of failure
>> considerably.
> If you do it manually, yes.
> And of course after all that, even for direct git access, recreate a
>> boost-header tree (either moving files or symlinks).
>> I repeat.. More testing complexity :-(
> Again: if you do it manually.

OK.. What's is the not manual way to do this without having git?

> Absolutely! Boost should continue to provide monolithic packages. And these
> packages need to be tested.
> What we want to modularize is the development. Not the package that we
> provide to end users.

Right.. And hence this thread about moving the testing infrastructure to
the github base. Note.. At this point I only really care about the
implementation practicalities. Because as it is, there's a rather small
chance of getting all this working for the target dates.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost list run by bdawes at, gregod at, cpdaniel at, john at