[Ns-developers] release update

[craigdo@ee.washington.edu]

> > Why force tests to look like builds?  I don't get it,
> 
> Because this is the way tests have traditionally been run in the free
> software world. i.e., "make test" works for every autotooled package
> and, whether we like it or not, we are trying to be good 
> members of that
> community which includes trying to adopt its conventions.

???

I would accept your argument if we were really using such a system -- where
we expect a user to type

  ./configure
  make 
  make test
  make install
  csma-multicast

In that case, it would make perfect sense to continue using "make test" and
a bit odd to do everything in the standard way BUT testing.

I might even buy it if we used

  ./waf configure
  ./waf
  ./waf test
  ./waf install
  csma-multicast

and we expected a one-to-one mapping between waf functions and
configure/make functions.  However, I simply do not buy the argument that
using "./waf check" is somehow more aligned with *anything* given our
current system.

I'm sorry, I just don't see it at all.  It's all completely different at all
levels from the GNU version.  What makes sense to me is to provide and
document a simple way to configure, build and test the system that is easy
to modify and maintain.  The extensive documentation we provide on how to
download, build and test ns-3 could just as easily have a line that reads,

  ./test.py

versus

  ./waf check
  ./waf --regression 

I mean, if I were walking up to this system with just autotools experience,
the correct sequence of commands to download, configure, build, test and run
an ns-3 script wouldn't just *occur* to me -- I would read the dox.  Then I
would find either "./waf check" or "./test.py" and do it.

IMO Using a test.py makes maintaining the test execution easier and has
basically no affect on the user.

I wouldn't have thought this would be controversial.

-- Craig