Quoting nathan binkert <n...@binkert.org>:
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. I
know some of Nate's recent changes suggested this was going to get
easier. Could you quickly summarize what that's all about, Nate?
What changes are you thinking of? I'm not sure that anything I've
done makes this easier or harder. I think it's just a matter of
creating SConscript files that the SConstruct file sources.
A mechanism where I can say binary foo needs file bar, and then when I
tell it to build foo it build's it with bar, and bar doesn't get mixed
in to other things. I think you're new widget that was like mercurial
patch guards would help with that, right? You could have a guard for
each extra target.
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?
I've looked into this in depth and I think that SCons just sucks for
this sort of thing. I've seen a few different proposals for dealing
with this, but they all seem to suck. Basically SCons builds the
dependence graph up front and then walks it. It doesn't seem to be
able to build it on the fly. (WAF is different in this regard.) That
said, there are hacks out there to get around this, but I haven't
managed to get them to work and I'm not sure if they're fragile or
not.
That's unfortunate.
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.
Running SCons twice in the way you suggest would be FAR slower than
just running SLICC and the ISA parser twice the way we do. Also,
notice that when SLICC is run twice, the modes are very different.
The first time it is run, it does parse the files, but only to figure
out what the dependencies are. The second time it runs, it is run in
the mode to actually generate the files. We parse all files twice
anyway to get the dependency information (scanners parse things like
.cc and .hh files to figure out dependencies with #includes, though
they basically just use regexes to do it). I think you should do this
with the ISA parser.
I'm not sure how SLICC is structured, but it might be hard to get out
file information without running the whole description, depending on
how the multi-file output thing is implemented. I wrote an email about
this a while ago, but basically it depends on if the output files are
more like a list or a program. #include files are like a list where
you can scan for them and know what they are without caring about any
of the other text (or at least are sort of like that). The mulit-file
output may be a lot more programmable and would be like determining
what files a program is going to generate at run time. You could build
in a dry run sort of mode that would just figure that out, but ISA
descriptions tend to be pretty complicated and that would be a
maintenance headache. It might still work out, though, since the
descriptions tend to be relatively quick. That's compared to building
the ginormous files they produce which can be S.L.O.W., especially if
you start swapping.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
