Boost logo

Boost :

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

On Wed, Dec 12, 2012 at 9:49 AM, Beman Dawes <bdawes_at_[hidden]> wrote:

> Starting a new thread - this is far to important to bury in the long
> documentation thread!
> On Tue, Dec 11, 2012 at 10:52 AM, Rene Rivera <grafikrobot_at_[hidden]>
> wrote:
> >What is the procedure that testers will follow?
> I've been assuming testers will follow the same general procedure. But
> other than verifying that hand-invoked b2 runs tests as expected,
> nothing else has been done that I'm aware of.

By that you mean invoking b2 on what project? Did you run anything before
that to set up the tree? Did you run b2 in the boost-root/status directory?
Or to simplify the question.. What precisely has been done already? As I
don't want to duplicate effort.

> > Is there documentation equivalent to <
> >> for the
> new
> > setup?
> None yet. I've been assuming we will just update
> > What changes to the current tools need to happen to the adjust to
> > the new setup?
> As a first cut, branch the current tools and convert any code that
> currently uses svn commands to use git commands.

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

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.

> Do you feel comfortable enough with git to handle the conversion?

I am familiar with DVCS concepts.. And intimately versed in VCS systems.
But, no, I am not comfortable with git command specifics. And frankly.. I
don't want to be. But also the requirements of regression testing are
fairly minimal when it comes to interfacing with the repo that the
non-expertise on my part doesn't really matter. And if it starts to matter
then I would consider it a failure of the system.. And would look for ways
to make the testing simpler at the cost of management at the github level.
Or to put it another way.. I will avoid complex testing tools at
considerable cost as they make for fragile testing.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

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