[Apologies for the delayed reply; I had to fish the message out of
Gmail's spam folder.]
Rob Savoye wrote:
On 12/11/18 7:59 PM, Jacob Bachmeyer wrote:
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?
In 1996, when that file was written, nobody was using the unit test
API at all. Later on, that didn't change much. :-) All the toolchain
components had their own internal API, but I thought a unit testing API
for compiled code was a good idea. (GCC's compile tests are different)
It never got a really heavy usage till I used the unit test API for
Gnash 10 years later. I'm using it now for another project, and haven't
seen the problem you mentioned. Maybe I'm just lucky...
I am also using dejagnu.h in another project and have not seen that bug
there, only "here" and only with testsuite_file.test, not the other test
cases. I do not yet know why. The most notable difference is that the
DejaGnu internal unit tests currently use a different protocol and are
in Tcl, while my other project is using dejagnu.h to test C code.
(Harmonizing the internal testsuite with dejagnu.h is on my TODO list,
along with documenting the unit testing protocol and separating "spawn
unit test" and "read unit test results" (as my project's own testsuite
does) thereby reducing host_execute to a backwards-compatibility entry
point. The main reason to split those apart is to better support
running unit tests remotely later.)
I can't remember any specific reasons that approach (libsup) wasn't
used for anything more than an experiment. Around that time I was
getting ready to start eCOS, so probably just didn't have the time for
something few were interested in.
So there was simply no time to pursue it (rather than any known
show-stopping problems) and my time spent looking into it would not be
wasted, then. Thanks.
-- Jacob
_______________________________________________
DejaGnu mailing list
DejaGnu@gnu.org
https://lists.gnu.org/mailman/listinfo/dejagnu