Boost logo

Boost :

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-12-25 10:23:03


On 12/17/2012 12:25 PM, Dave Abrahams wrote:
>
> on Sun Dec 16 2012, Rene Rivera <grafikrobot-AT-gmail.com> 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. https://github.com/ryppl/ryppl/blob/develop/scripts/github2bitbucket.py#L40
>
> In fact, I think someone has coded up what's needed to make a monolithic
> zip here:
> https://github.com/quarnster/sublime_package_control/commit/9fe2fc2cad9bd2e7e1a38d7e5d4aaa02fb2b4aea

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.

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 :-(

>>> But before any testing is done, it would be helpful if Boost.Build was
>>> updated to handle the generation of boost-root/boost header file
>>> links, rather than relying on the workaround cmake script.
>>
>> Well.. In an ideal world it would be possible to have a fully integrated
>> "monolithic" repo that the testers can just use as that is the simplest and
>> likely most repliable path. But, alas, this hope of mine was essentially
>> dismissed during the DVCS/git discussions.
>
> This isn't about DVCS but about whether we're going to have real
> modularity.

I don't know what you mean by "real modularity". But the testers *must*
test what Boost delivers as a package. At some point end users get a
Boost installed. And that's what we have to test. If we don't test that
we will have unknown issues to deal with.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk