On Sun, Apr 22, 2012 at 10:40 PM, Gabe Black <[email protected]> wrote:
> > [...] there are two problems I ran into/can remember. > First, scons can't figure out what python files matter as far as > rebuilding things. If it doesn't know that foo.py is imported by bar.py > is imported by main.isa's let block, changes to foo.py will not cause > things to be rebuilt without a lot of arm twisting. Because the isa file > include mechanism is more explicit and easier for scons to follow, it > works better in that sense. Interesting, that hadn't occurred to me. I can see where people who write build tools don't generally bother to track file dependencies for interpreted languages. Given that the isa parser runs as one monolithic process, one inelegant but likely effective approach would just be to add an explicit scons dependency on every .py file in the isa directory tree (and we could find the files by walking the tree if we didn't want to have to name them manually). Now that I checked, it looks like that's pretty much what you already do with the existing .py files in arch/x86/isa/insts. So I guess we could just extend that to any other .py files that get created. > Also I think there were problems with the > python search path. > I'm not too surprised on this one, but it can be fixed, if nothing else than by pulling out our ugly but trusty friend addToPath(). > As you mention, Steve, I'd ultimately like to turn the whole thing > inside out so that the ISA description stuff is embedded in normal > python code, probably as a python library. > I know you've mentioned that before, and I'm curious how you envision that working. I find the syntactic conciseness of the existing language very valuable. I know it doesn't work well for x86, but my inclination would be to fix/extend the language rather than getting rid of it. I'm open to considering a different approach, but I'm not ready to endorse it. Then again, this could be one of those places where the way we each describe what we want diverges more than our actual ideas do. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
