Bug 478 – ./waf --regression should be able to, by default, look for traces in ../

Bug 478 - ./waf --regression should be able to, by default, look for traces in ../


Summary:	./waf --regression should be able to, by default, look for traces in ../

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	build system
Version:	ns-3-dev
Hardware:	All All

Importance:	P5 normal
Assigned To:	Gustavo J. A. M. Carneiro

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2009-01-22 00:17 UTC by Tom Henderson
Modified:	2009-01-24 10:48 UTC (History)
CC List:	1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Tom Henderson 2009-01-22 00:17:10 UTC

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.