"Robert Ramey" <ramey@rrsd.com> 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