In general this sounds good... it seems like one issue that we're touching on is that for many current tests we have a sparse matrix of applicability: there are ISAs, configs (with and w/o ruby), OSes, etc. It would be nice to specify a related set of tests concisely but it's actually complex to precisely generate the set of tests since there are a lot of exceptions. (That's what I was getting at with my comment about using a dict.)
The current scheme actually does that well, since there's no need to redundantly list a test somewhere else once you've created the reference directory. I think the idea of putting the SConscript file directly in the reference dir is a good way of achieving the same thing in a more elegant and robust way. Ideally you could simply use '.' as the default reference dir for the Test function. If we make that the canonical way of adding a test, then maybe we don't need to build up any standard structure (or "convenience stuff" as you put it) for doing it in more complex ways. You could still build more complex structures (e.g., maybe you'd need to if you wanted to define inter-test dependencies), but we wouldn't have as much need to design explicit mechanisms for that. On Mon, Mar 8, 2010 at 8:32 AM, nathan binkert <[email protected]> wrote: >> So we could have something more like this (just using current paths >> for backward compatibility): >> >> Test('quick/00.hello/ref/%s/linux/simple-atomic' % env['TARGET_ISA']) >> >> if env['TARGET_ISA'] == 'alpha': >> Test('quick/00.hello/ref/alpha/tru64/simple-atomic') > I think we have to avoid this because currently TARGET_ISA is inferred > (something I'd like to fix). Since it is inferred, there's no easy > way to force dependencies to be checked and built. Good point... I agree, this doesn't work, the test will need to encode the applicable ISA(s) directly. One thing this brings up is the situation with tests like memtest, where it's independent of the ISA, but unless you're insanely paranoid, there's no reason to run it N times when you're doing a global regression just because you've built N binaries to test N different ISAs. Maybe the same is true for other internal unit tests. We'll have to work in a special case for these kinds of things, I think. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
