[Ns-developers] Proposed examples directory hierarchy

[Tom Henderson]

On Tue, 6 Oct 2009 11:51:49 -0700, <craigdo at ee.washington.edu> wrote:
> Hi Tom,
> 
>> For the release, I don't mind reorganizing the examples 
>> (which seems to 
>> be a separate issue) and putting the pending examples of bug 
>> 612 in, and 
>> if we could restore ./waf --check's behavior after bug 609 was fixed 
>> (couldn't you make ./waf --check do "./waf --target test-runner; 
>> ./test.py -n -c bvt -c unit"), that would be enough for me.
> 
> I made a couple of very small changes that adds to the flexibility and I
> think gets you what you want.
> 
> First, if you do nothing, and use "./test/py" you get existing behavior.
> Everything is built.  This is nice for a newbie user who is just going to
> download, build and start poking around.
> 
> If you know what you are doing, you can get more flexibility.  If you
leave
> --enable-examples set, you build all of the examples and samples once at
> the
> beginning and then use dependencies after that to control what is built.
> This seems useful for the ns-3 maintainer-types who will need to
> periodically make sure that they haven't broken any samples or examples
but
> aren't generally interested in examples and samples.
> 
> If a maintainer makes a change to the core (with --enable-examples
> configured), he can run "./test.py -c core".  This tells test.py to
> constrain itself to running only the ns-3 core tests (BVT, UNIT and
> SYSTEM).
> This means that only the test-runner is built which has dependencies on
all
> of the core tests.  No examples or samples will be built.  If Mr.
> maintainer
> then runs "./test.py" (with no constraints) all of the examples and
samples
> get built; and test.py runs all of the examples (it should really run
> samples too, but that's another thing).  If he makes another change to
the
> core and runs "./test.py -c core" only the test-runner is linked and none
> of
> the examples and samples are built.  I think this is what you wanted.
> 
> If you are an experienced user writing your own models (and really not
> caring about running examples or samples) you can just turn them off and
> not
> deal with them at all using "./waf configure --disable-examples".

This sounds good to me.  I had a few more questions, though:
1) Can "./waf --check" run "./test.py -c core"?  I recall we had discussed
keeping this API alias, as being analogous to "make check".  
2) what becomes of "./waf --regression" and "./waf --valgrind --regression"
for this release cycle?  I presume we are just keeping them in for now.
3) is there an easy way to enable valgrind via test.py? 
4) is there an easy way to enable gdb for debugging problems that test.py
uncovered in the tests that are not example programs?  This is what I
documented so far:
http://www.nsnam.org/docs/testing/testing_19.html#SEC24

Thanks,
Tom