Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-20 08:30:49


Johan Nilsson wrote:

>>> > That should not happen? Which V2 version do you use? In M10
>>> > (http://zigzag.lvk.cs.msu.su/~ghost/Milestone_10_preview/), which is
>>> > due
>>> > soon, the 'unit-test' rule adds the proper DLL paths.
>>>
>>> I'm using the latest cvs version. Is there anyway to run the staged file
>>> using the cvs version, preserving tags etc?
>>
>> None that I know, as unit-test is supposed to do that. A future version
>> will
>> have "notfile" target which allows to run arbitrary actions, but:
>> - I'm not sure that will be convenient for running staged exes
>> - It's not implemented yet
>
> Isn't notfile a "built-in target" already in Jam/MR?

I recall it is, but V2 "notfile" would be able to depend on other targets,
for example.

E.g. I'd imagine this:

notfile test : dist : "qmtest -D tdb run" ;

which would first build "dist" and then run a command.

>>> How can the unit-test rule know the proper DLL paths? I've got a couple
>>> of
>>> import libraries under deps/libs as well, with the corresponding DLLs
>>> under
>>> bin.
>>
>> Good catch. On Linux, if exe (or unit-test) uses a shared lib file
>> (including
>> prebuilt one), it will add the right paths. I've just realized that
>> import libs on windows do not work as nice.
>>
>> However, you can try:
>>
>> lib whatever : : <file>whatever.lib <file>whatever.dll ;
>>
>> so that V2 knows there's DLL involved.
>
> How about the paths in this case?

They *should* be right, but on a second though I'm not sure that's the
case :-( The <dll-path> should work for sure.

>> Or you can add <dll-path>deps/libs to your project requirements to make
>> unit-test add that path when running tests.
>
> I assume you mean <dll-path>bin ?

This depends on where you put your prebuilt DLLs. I though they are in
"deps/libs".

> Btw, how that implemented? Do you set the path in a .cmd file that runs
> the test, or?

The full story:
- when ordinary shared library is built it adds the path where it's
generated to <xdll-path> usage requirements -- that's a property that's
returned together with created targets.
- when unit tests are run, the <dll-path> and <xdll-path> properties are
collected and proper PATH elements are added when running the command.

You can look at the 'capture-output' rule in v2/tools/testing.jam and at the
'run-path-setup' rule too.

- Volodya

 


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