[Ns-developers] release update
craigdo at ee.washington.edu
Wed Jun 10 12:30:16 PDT 2009
> > 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
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
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
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,
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.
More information about the Ns-developers