Re: [boost] bjam in lib/<x>/test is equivalent to run.py

Subject: Re: [boost] bjam in lib/<x>/test is equivalent to run.py
From: Jim Bell (Jim_at_[hidden])
Date: 2010-11-06 09:17:54

On 1:59 PM, Rene Rivera wrote:
> On 11/5/2010 10:32 AM, Jim Bell wrote:
>>
>>
>> On 1:59 PM, Rene Rivera wrote:
>>> On 11/4/2010 12:31 PM, Jim Bell wrote:
>>>> To make your own script to rebuild/rerun a particular test, run bjam
>>>> with -d+2 (i.e., -d2) and direct the output to a file. Then copy the
>>>> compile&   link commands out of that file.
>>>
>>> Or you could just run: cd libs/<x>/test ; bjam -a<name-of-the-test>
>>> Doing a "bjam -h" or "bjam --help" will point to other useful switches.
>>>
>>
>> Let's say you're troubleshooting a thread library problem that only
>> shows itself during an asio test.
>>
>> Can you make changes to a thread file (e.g,
>> libs/thread/src/win32/thread.cpp), then re-run bjam in libs/asio/test
>> with the appropriate -a flag, and have your thread change be picked up?
>> I.e, boost thread library rebuilt, app rebuilt, app re-run.
>
> Yes. Boost Build does full dependency analysis. Assuming the
> dependency on ASIO is setup for Threads. Which would be a bug onto
> itself ;-) Of course if you've been around here long enough you must
> know that the dependency scanning is not perfect, and it is confused
> by things like PP generated include names. Which are common when using
> Boost PP for code generation.
>

Granted. And it's reasonable to say "keep an eye on it, and if you
suspect anything, pass the '-a' flag." (It's the halting problem in the
dependency analysis domain.)

Thanks.