On Sun, 2008-03-02 at 19:38 -0500, Dan McMahill wrote: > Peter Clifton wrote: > > > We should probably do 1.4.1 soon actually. I hope to get the gnetlist > > test suite in before then, and Ales wanted intltool disabling - which I > > agree is probably a good idea. > > Is this a new test suite or additions to what is there?
It took the spice-sdb bit, and made it apply to every backend. Other than for spice-sdb, it is based on golden files, not a meticulously hand-checked output. Take a look at the last few commits here: http://repo.or.cz/w/geda-gaf/pcjc2.git > I've been wanting to rework it a bit. Portions require gnetlist to be > installed first which is a bit backwards. Also I think there are some > remaining issues around building outside the source tree. It should all > be fixable though. I do think it would be good to move all the gnetlist > tests into the same framework though. Indeed. I've not addressed the "must be installed" issue though. > That makes maintaining it much > easier. We probably should also make it so it runs all of the tests and > then reports how many passed and how many failed. Currently the tests > stop on the first failure which is a bit annoying. I don't think that is the case for a large number of them. (Spice-sdb etc..) > The framework in the spice-sdb area is based on what I did for latex-mk > (yet another oss project of mine) and in latex-mk it worked fairly well. > We used pretty much the same approach in gerbv and I think it is > working there. We can probably add any needed extensions to make it > work for all of the gnetlist tests. Basically the idea is you have a > text file that defines each test. The test is given a name, some data > like input files, extra command line arguments, and an expected exit > code. Then there is a script which goes over each test and runs it. > The script has hooks in there for easily regenerating "golden" files. You'll see how I've hacked it.. I'm sure it (my changes) could be done neater though. Part of the problem is that some backends require different files copying. For example, the DRC or BOM backends want a file listing attributes to care about. I added a "copy list" for every test, which avoided having to re-state that file every time. It could have been per-backend, but I didn't see any benefit in making it that complex. I also allowed myself a grossly dirty hack (for testing the regressions), in that it renames the VHDL (or was it verilog) output file, since that backend doesn't save every file according to the -o .... option. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
