[Ns-developers] release update

[Tom Henderson]

> Hi Craig,
> 
> I share your sentiments regarding WAF internals being ugly.  This is a
> reflection of the way WAF is being maintained, and I lost this battle a long
> time ago :-(  I would have forked WAF a long time ago if only I had time to
> maintain the fork...
> 
> I think it is plausible to have the testing outside of WAF, if you can
> easily code a task scheduler in python that handles concurrency and task
> dependencies; however, you have to agree it should at least be invoked from
> WAF.  That is, "./waf check" should invoke the test script.  The test script
> should accept parameters to indicate what build variant we are testing
> (debug/release), and any other useful information that waf knows more
> easily.
> 

What about these use cases?

1) user downloading ns-3 and building for the first time
cd ns-allinone-3.X
./download.py
./build.py
./test.py -> this cds into ns-3-dev (or whatever repo was downloaded) 
and runs utils/test.py

2) developer who is working on ns-3-dev without bumping up to 
ns-3-allinone level:
./waf test -> wrapper that runs utils/test.py, as Gustavo suggests above
./waf check -> no change to existing ./waf check; run unit tests only
./utils/test.py [arguments]  -> explicitly run with arguments rather 
than let ./waf fill them in for you (such as debug/optimized...)

"test" (full execution of test.py) vs. "check" may seem redundant, but I 
don't run --regression nearly as much as check (which also triggers 
introspection for me) and I don't run --valgrind --regression nearly as 
much as --regression.

(by the way, is there a plan for supporting valgrind in test.py?)

- Tom