Bugzilla – Bug 335
./waf --regression no longer works without mercurial present
Last modified: 2008-09-14 21:33:40 UTC
regression should download traces from web, not crash [craig-dowells-imac] ~/tests/ns-3.2-RC2 > ./waf --regression Entering directory `/Users/craigdo/tests/ns-3.2-RC2/build' Compilation finished successfully ========== Running Regression Tests ========== Traceback (most recent call last): File "./waf", line 141, in <module> Scripting.prepare() File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 207, in prepare main() File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/Scripting.py", line 299, in main if fun:fun() File "/Users/craigdo/tests/ns-3.2-RC2/wscript", line 448, in shutdown run_regression() File "/Users/craigdo/tests/ns-3.2-RC2/wscript", line 911, in run_regression if subprocess.Popen(["hg", "version"], stdout=dev_null(), stderr=dev_null()).wait() == 0: File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/pproc.py", line 123, in __init__ self._execute_child(args,executable,preexec_fn,close_fds,cwd,env,universal_newlines,startupinfo,creationflags,shell,p2cread,p2cwrite,c2pread,c2pwrite,errread,errwrite) File "/Users/craigdo/tests/ns-3.2-RC2/.waf-1.4.2-81764acf62a7c7247901b9a99367b3a2/wafadmin/pproc.py", line 424, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory [craig-dowells-imac] ~/tests/ns-3.2-RC2 >
Should be fixed by rev. 3677.
I just built a new release and this still happens.
*** Bug 342 has been marked as a duplicate of this bug. ***
It is not clear that this is still a bug. The test procedure to reproduce on the current release candidate is ./waf configure ./waf --regression (remove mercurial) ./waf --regression (crashes) whereas Mathieu suggests that this is operator error to change the platform (remove mercurial) and not rerun configure.
Well, I don't know about operator error. The way the test for hg has been done has changed. The sequence Tom posted worked fine until last week, but the test for hg is no longer dynamic, it is now based on configure results; so the way the regression tests work has quietly changed. That said, I'm fine with having to type configure in order to change how the regression tests behave. It just means changing (slightly) the way I've been doing some of the final tarball tests. This is a case where I knew too much about how the internals of the wscript were working and I knew I could do this without doing the configure. I'll go ahead and (re) close this bug and assume that our policy from now on is that any change to the underlying system like this requires a ./waf configure (and that any future test should be based on configure results).
(In reply to comment #5) > Well, I don't know about operator error. The way the test for hg has been done > has changed. The sequence Tom posted worked fine until last week, but the test > for hg is no longer dynamic, it is now based on configure results; so the way > the regression tests work has quietly changed. > > That said, I'm fine with having to type configure in order to change how the > regression tests behave. It just means changing (slightly) the way I've been > doing some of the final tarball tests. This is a case where I knew too much > about how the internals of the wscript were working and I knew I could do this > without doing the configure. > > I'll go ahead and (re) close this bug and assume that our policy from now on is > that any change to the underlying system like this requires a ./waf configure > (and that any future test should be based on configure results). > I think it is reasonable to reconfigure when the system changes. I would not have reopened the bug for that reason.
I don't want to belabor this, but I didn't open the bug because "the behavior changed to reconfigure when the system changes." I reopened the bug becuase I had successfully tested the "fetch-the-bits-rom-the-web" behavior many, many times without reconfiguring over the past seven months; and when I tried it for the nth time last week, it failed. I opened the bug because, from my perspective, regression withot Mercurial was *broken*. I used it the way I had used it since April, and it no longer did what it used to. This is usually called a regression, although in this case it turned out to be an (I'm pretty sure) undocumented behavioral change. This bug begs the question of how changes to the build system (or the existing build system) are documented. We have tons of documentation on API, but really nothing on build options. There should have been a place to note this change.