Quoting Steve Reinhardt <[email protected]>:
On Tue, Apr 19, 2011 at 3:00 AM, Gabe Black <[email protected]> wrote:
I was looking at some of the stuff in util, and it occurred to me that
the m5 utility program is cross compiled using different Makefiles for
different architectures. Statetrace used to be like that (sort of), but
recently I converted it over to scons and set up some configuration
variables that made it easier to work with. It would be nice to be able
to share some of that with the m5 utility program, although I don't
remember it being all that complicated.
Anyway, it seems like it would be useful to be able to have multiple
binaries that can be built by scons, specifically the utility stuff and
unit tests. That way we could avoid having a hodge podge of small build
systems which are either isolated or not in not quite the right ways.
If you're suggesting that the stuff in util get built by scons and put
the binaries somewhere like build/util, I think that's a great idea.
I don't know of the pros and cons of making it an "indepedent"
invocation of scons vs integrating it into our global scons
configuration, but whatever way we do it should avoid redundant scons
code for things like detecting your compiler version, which makes me
think the integrated approach might be better. Either way might
require some refactoring between the SConstruct file and
src/SConscript, since it's not under src, but we should be able to
work that out.
Great. I think that will make the util stuff more first class citizens
of the repository and not just some handy stuff tacked on the side,
although there is value in that sort of thing as well.
Also, I was thinking about how to handle the dependencies/generated
files/custom language issue a little while back, and what I kept coming
back to were schemes where scons would use a cache of dependency
information which it would regenerate if any of the input files which
determined outputs and/or dependencies changed. The problem is that
scons would need to run once and possibly regenerate its cache, and then
run again to actually run. Is this sort of multi-pass setup possible
somehow without major hacks?
To explain more what I'm getting, lets say you have input file foo.isa
which, when processed, generates the files foo_exec.cc and bar_exec.cc.
What would happen is that you'd have a file like foo.isa.dep which would
describe what would happen and make that depend on foo.isa.
When you run for the first time, scons would see that foo.isa.dep
doesn't exist. During it's build phase, it would run foo.isa through the
system and see that it generated foo_exec.cc and bar_exec.cc and put
that into foo.isa.dep (as actual SConscript type code, or flat data,
or...). When scons ran the second time, it would read in foo.isa.dep and
extract the dependencies from it and build that into the graph. It
wouldn't construct foo.isa.dep again since all its inputs were the same,
and it would still capture all those dependencies. This time around, the
larger binary would see that it depended on foo_exec.cc and bar_exec.cc
and that those depend on foo.isa.dep (as a convenient aggregation point
of all *.isa files involved). If foo.isa changed later, foo.isa.dep
would be out of date and have to be regenerated, and then foo_exec.cc
and bar_exec.cc, and then the main binary.
The net effect of this is that the thing that processed the .isa would
only be run when necessary. In our current setup, that would mean SLICC
wouldn't have to be run for every build, only ones where the SLICC input
files changed. The problem here is that scons would need to basically
call a nested instance of itself on foo.isa.dep, let that build a dep
tree and run the build phase, then process foo.isa.dep in the parent dep
phase, and then run the parent build phase. It could literally just call
scons from scons (though that seems like a major hack) or it could, if
scons has a facility for it, do some sort of fancy multi-pass thing.
This is sort of related to the first thing (additional targets) because
the dependency cache files are sort of like independent targets with
their own invocations of scons.
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. 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.
Also related to scons are those .pyc files that end up scattered around
the source tree. I know I asked about those a long, long time ago, but
why are they there? Why don't they end up in the build directories?
That's an artifact of including them in scons, where they're run in
place and not by m5.
Ok. For some reason I had convinced myself that wasn't what was
happening for some reason, but I can't remember any specifics and I
can't look into it at the moment.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
