From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-09-24 11:47:26
Vladimir Prus <ghost_at_[hidden]> writes:
> I've some question about the way V1 regression system works (I'm just in
> process of porting it to V2).
> 1. The 'run-test' rule contains the following:
> # Move important data from the test target to the executable
> gRUN_LD_LIBRARY_PATH($(executable)) = $(gRUN_LD_LIBRARY_PATH($(parent))) ;
> gRUN_PATH($(executable)) = $(gRUN_PATH($(parent))) ;
> Who sets this data on 'parent'?
Various things. If parent is a shared lib, it's the shared lib
construction rules. You can also look for that variable use in
python.jam. It's easy enough to find all the places with a grep-find.
> 2. It seems like for "RUN" tests, the output is first sent to ".output" file
> which is then copied to ".run". Why the extra copy is needed?
I don't remember. Oh, yeah: it's because Jam deletes targets which
fail to build, but we want to leave behind a copy of the output even
if the run test reports an error.
You can learn alot about all this by looking at
> 3. The 'capture-run-output' rule contains:
> INCLUDES $(target) : $(target:S=.output) ;
> First, I don't understand why this statement is needed.
Me neither. Usually that's done to suppress a warning about
independent targets, and I think the .output file isn't in the
dependency graph otherwise.
> Second, while .output is in dependency graph, I don't see any
> updating actions for it, or NOCARE statements for it. So, bjam
> should complain that the target is not found. But, it does
> not. Anybody knows why?
because of INCLUDES, probably.
> 4. The ".test" file constains the name of sources. Why is this necessary?
Beman wanted it at one point for the regression tools.
> 5. The link and link-fail rules are not used in Boost testsuite. Are they
> implemented for completeness only or they are used somewhere?
They were used once upon a time, at least.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk