[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