On Tue, Apr 19, 2011 at 3:13 PM, Gabriel Michael Black <[email protected]> wrote: >> >> Caching the list of generated SLICC files sounds like a good idea to >> me. I'm not sure this would require recursive scons invocations, >> since we manage to build the list dynamically already without that. I >> wouldn't call it a cache of "dependency information" though, since >> scons already has one of those; this is really just a cache of >> generated filenames, right? > > How would you be able to do it all in one shot? The tricky part is that you > actually have to build the .dep in the build phase, but you need it in the > dependency tree generating phase. Since you can't go backwards like that in > one invocation (as far as I know or can imagine) then you'd need to rounds.
OK, I see, maybe it is inherently another level beyond what we currently do. I'm not the scons expert... > As far as what it would be caching I think it's largely a semantic > difference. You could consider it a cache of generated files which are used > to set up the dependencies. It's just terminology... not that it's wildly inaccurate to call it "dependency info", since it is info that is eventually used to determine dependencies, just that there's already a "dependency caching" feature in scons that's totally different (http://www.scons.org/doc/2.0.1/HTML/scons-user.html#AEN1148), and in general when the scons docs talk about dependencies it's "what are the files that this file depends on" not "what are the files that depend on this file". Thus it would be less confusing if you avoided referring to the info that you're discussing here as "dependency info" and used a different term like "generated file info". That's all. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
