[boost] Re: [Boost.Test] New testing procedure?

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-23 13:46:56

"Robert Ramey" <ramey_at_[hidden]> writes:

> What I mean is:
>
> Test.cpp only depends on module1.cpp which Is in the library.  The functions
> in module1.cpp can only be accessed by including header1.hpp in the test
> either directly or indirectly.  Suppose module2.cpp gets recompilied.  This
> provokes a rebuild of the library which provokes a rebuild of
> test.cpp

No.  Unless you changed header1.hpp, the test will be relinked; that's
all.

> and rerunning of the test.  This occurs even though this isn't
> necessary as module1.cpp - the only module the test depends upon -
> hasn't changed.  

If you did change header1.hpp, and you're getting unneccessary
recompilations, it indicates that your header granularity is too
coarse.

> In other words.  The dependency granularity is the library - not the
> modules within the library.  

Not for recompilation.  For linking, that's true and appropriate.

> My understanding comes from study of BJAM and observation of my
> system when I make a change.  I would be very pleased to find out
> that I'm wrong about this.

So you're pleased now? ;-)

> So let me see if I have this right.
>
> a) I can check in a different version of runtest that will set my "testing
> level" appropriate for the state of the library and change it as necessary.

I don't know; what is runtest?

> b) I can specify which compilers should be included/excluded from the test.
> (somehow - I don't know how yet)
>
> c) If something changes that effects any code/header module used by the
> library - everything is going to be rebuilt and tested regardless of the
> dependency of the particular test.

I don't have the context to understand anything in that list.

> OK - given a and b I think this can be made to work with relatively little
> difficulty.

I don't know what I can give you ;-).

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com