[Ns-bugs] [Bug 478] New: ./waf --regression should be able to, by default, look for traces in ../
code@nsnam.ece.gatech.edu
code at nsnam.ece.gatech.edu
Wed Jan 21 21:17:10 PST 2009
http://www.nsnam.org/bugzilla/show_bug.cgi?id=478
Summary: ./waf --regression should be able to, by default, look
for traces in ../
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: build system
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
Estimated Hours: 0.0
If build.py/download.py is used, a python constant to store where the reference
traces are located, and ./waf doesn't require a "--with-regression-traces"
argument at configure stage.
If, however, another repo is cloned or copied in parallel to the existing
ns-3-dev, one must specify the regression trace location in configure.
For my workflow, it would be convenient if ./waf --regression in ns-3-dev
checked first whether --with-regression-traces was set, and fallback to
checking ../ns-3-dev-ref-traces by default. This is because I often keep a
sync'ed ns-3-dev in my local filesystem and just copy it to work on specific
bugs or work projects (such as ns-3-dev-bug458).
I would even be fine with setting a local env var such as
DEFAULT_NS3_REF_TRACES that could be checked as a default if
--with-regression-traces were not specified. Such an env. var option would
enforce less policy.
Same could hold true for pybindgen and nsc.
Another option would be to use something like "build.py -n ..." but ./waf is
hard to configure in that manner.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Ns-bugs
mailing list