bjam in lib/<x>/test is equivalent to run.py
Compelled as I am to audit everything, I had to compare running bjam in the lib/<x>/test directory with run.py. I'm confident that they do produce (essentially) the same compile, link, and execute commands. Notes, from a regression-runner's POV: * They use different directories: run.py uses {boost-root}/../results/bin.v2/..., and bjam uses {boost-root}/bin.v2/... * run.py sets up bjam with a lot of flags, like --debug-configuration [shouldn't matter for most people] -d2 [important for many, described below] -lxxx [that's lower-case L, with a time-out in seconds: potentially important] preserve-test-targets=off [not sure if this matters or not] * run.py runs from the boost/status directory, I think. Might matter for some tests. Not sure about straight bjam. 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. The -lxxx command (e.g., -l120) matters if a test could hang (e.g., <https://svn.boost.org/trac/boost/ticket/4766>).
On 11/4/2010 12:31 PM, Jim Bell wrote:
Only important for regular regression testers as they need to make sure there are no runaway tests that impede the testing progress for other tests. Only important for authors/debuggers if they want to account for the regression tester environments, i.e. to make sure tests run in a reasonable amount of time.
Should not matter for anyone but regression testers. Since it's designed to save disk space only.
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.
The -lxxx command (e.g., -l120) matters if a test could hang (e.g., <https://svn.boost.org/trac/boost/ticket/4766>).
Right :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 1:59 PM, Rene Rivera wrote:
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.
On 11/5/2010 10:32 AM, Jim Bell wrote:
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. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
At Thu, 04 Nov 2010 12:31:08 -0500, Jim Bell wrote:
You can change where bjam puts it with --build-dir. Of course, that's what run.py does.
Not when testing, really. Any build command that fails will be dumped even without -d2
-lxxx [that's lower-case L, with a time-out in seconds: potentially important]
If you want to run the tests unattended, maybe
preserve-test-targets=off [not sure if this matters or not]
You might want it on for repeated build/test/debug cycles.
* run.py runs from the boost/status directory, I think. Might matter for some tests. Not sure about straight bjam.
Should not matter.
I think you may want to add -a. Using -o to specify the file is cleaner, or if you want to use -d2 then also add -n. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
David Abrahams -
Jim Bell -
Rene Rivera