On 03/29/11 13:34, Korey Sewell wrote: > Good point about regression carefulness Gabe. > > Although I'm pretty sure I compiled MIPS before I committed this, I > had forgot I touched other ISAs and obviously broke one of them. > That's just an error on my part.
Yeah, I didn't want to pick on you, Korey, you're change was just the most recent. I've done it too once in a while. We -all- need to be careful. > This brings up a few issues: > - Should the regressions be more resilient? In other words, if POWER > doesnt compile shouldnt the regressions still *try* for whatever CPU > model and ISA combinations it does compile for? (i'll add that to the > regression wants page) POWER_SE was totally broken because a central file (types.hh) would break anything that included it, so it probably wouldn't be possible to run them at all. Other ISAs are separate builds so those did run. Trying to find valid CPUs would likely be overkill since we should keep things building in the first place. > - It would be nice to somehow be able to localize the regression tests > you need to run after making changes. There's about 5 ISAs (?), 4 CPU > models , FS/SE mode, so if you make a particular change, sometimes its > unwieldy (albeit still necessary) to run every single test. Is there > an easy way to test just "what matters"? I run the quick regressions for any mode/ISA combination I touched or think I might have affected. Sometimes I guess wrong, but that's done pretty well for me. Then there are the things that aren't in the regressions at all, but we're working to fix that I think. > - Lastly, An overkill thing would be to have a "buffer-repo" sitting > between users' local repo and m5-dev. Then, nightly before the > regressions, you could conceivably test to make sure that builds (or > whatever other sanity check) and *then* check-in changesets to the > dev-repo after the initial 1st pass. This would ensure that any pulls > from m5-dev would always be compilable at the very least. That makes sense and was what I was hoping we could use m5-stable for, but we didn't end up doing that because we wanted m5-stable to be even more stable than that (although it tends to just be old, not necessarily stable). Maybe we need something in the middle that works like you're suggesting. Gabe _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
