dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

testsuite/lib/libsup.exp appears to be an interesting fossil


From: Jacob Bachmeyer
Subject: testsuite/lib/libsup.exp appears to be an interesting fossil
Date: Tue, 11 Dec 2018 20:59:48 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0

While recently improving the DejaGnu testsuite, I found that using "pass" in a unit test case that loads framework.exp produced an error: "PASS doesn't exist in incr_count". The immediate solution was "well, of course that does not work" and just writing {puts "PASSED: ..."} instead, but libs.exp uses a make_defaults_file procedure that turns out to be defined in libsup.exp. The libsup.exp file seems to mostly be a fossil, older than the 1997 ChangeLog entry that recorded grouping test counts into an array: the defaults file libsup.exp writes still contains the old variable names, leading to the error mentioned above.

The ChangeLog indicates that libsup.exp was added about a week before the *.test unit test cases were added, when the original unit test drivers that the *.test files replaced were written. (An apparent typo records the file as "testsuite/lib/libsupp.exp" but that is the only match for "libsup" anywhere in the ChangeLog that indicates a new file.)

Reading libsup.exp is interesting. The file appears to be mostly-unused infrastructure for running unit tests with an interactive Expect subprocess. This looks like a solution to the slightly inelegant {spawn -open [open "|$EXPECT ..."]} currently used in libs.exp. I had tried directly spawning each unit test process, but encountered a strange bug where the output could be truncated if the child exits before it has all been read. The dbg.log simply records "expect: read eof" and the "END" is never seen. This bug could be partially worked around by having the child sleep before exiting and does not occur if the child is connected using a pipe rather than a pty. For unknown reasons, this bug does not occur with my project's unit tests that use the same approach of directly spawning a subprocess connected with a pty. Using an interactive Expect shell would also solve the problem, as an interactive shell will not exit until so directed, and this provides a handshake that should solve the problem, as it seems to be a timing issue.

Is there a known reason that this approach (an interactive Expect subprocess) is not used, or was there simply not time to pursue it in early 1996?


-- Jacob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]