[LLVMdev] QMTest vs. Dejagnu

John Criswell criswell at cs.uiuc.edu
Mon Nov 29 08:25:33 PST 2004


Tanya Lattner wrote:
>>>Cons of QMTest:
>>> 1) You have to use the gui to add directories.
>>
>>I think you're wrong. Manually creating a directory would work, as QMTest does
>>not place anything special in directories.
> 
> 
> I may have worded this poorly, but I think you have to use the gui to add
> new directories or tests, or specific tests. Otherwise, it does not know
> what to do with those files. I get lots of warnings/errors from QMTest
> when it comes across a tests thats not in the database (says something
> like "could not load test".

You shouldn't need to add tests using the GUI; the source in llvmdb.py 
should pick it up automatically (llvmdb.py takes all of the test input 
files and presents it to QMTest as a test database).

However, if you add a directory (say, llvm/test/NewComponent), then 
llvmdb.py needs to be modified so that it knows that the directory is 
part of the test suite and knows which tests to run on the files inside 
that new directory.

Currently, all of this stuff is hardcoded into 
llvm/test/QMTest/llvmdb.py, but it could be made configurable (assuming 
we wanted to keep QMTest).

> 
> 
>>> 5) Intermediate output placement can not be controlled.
>>
>>I don't understand this one. The intermediate output is placed where tests
>>want it to be placed; QMTest does not create any such output itself.
> 
> 
> This could be how we have written our python files.. but right now if you
> run a tool and it generates some output.. where that output is placed is
> not controlled. So it makes it difficult to clean up this intermediate
> output.

Since, with QMTest, all tests are run from $OBJROOT/test, we don't want 
that control to reside with the tests (they'll place their temporary 
files in the wrong place).  Hence the addition of the %t replacement 
string in the Pyton version of TestRunner (%t provides the pathname of 
the temporary directory to use for files).

> 
> 
>>>I propose that we switch over to using dejagnu by default, renaming
>>>check-dejagnu to check, and deprecate QMTest. We can either remove qmtest
>>>for this release or keep it until 1.5.
>>>
>>>I'd appreciate your opinion or any feedback you may have.
>>
>>Looks like dejagnu is better for this task (though I always thought it's some
>>rusty tcl-based code). You might want to check on QMTest mailing list first,
>>in case they have some silver bullets at hand. After all QMTest was supposed
>>to test gcc, which is also cross-platform.
> 
> 
> Thanks for your feedback!!!
> 
> -Tanya
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

QMTest Quality of Implementation can be improved, but if Dejagnu already 
exists and works well enough, there is little reason to keep QMTest, I 
think.

-- John T.

-- 
*********************************************************************
* John T. Criswell                         Email: criswell at uiuc.edu *
* Research Programmer                                               *
* University of Illinois at Urbana-Champaign                        *
*                                                                   *
* "It's today!" said Piglet. "My favorite day," said Pooh.          *
*********************************************************************




More information about the llvm-dev mailing list