Quoting Steve Reinhardt <ste...@gmail.com>:
On Tue, Apr 19, 2011 at 3:13 PM, Gabriel Michael Black
<gbl...@eecs.umich.edu> 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...
Me neither... Anybody else?
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.
Yes, I see why that could be confusing. I won't call it that any more
(unless I forget).
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
