> 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.
> 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. > 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. > 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? SCons itself imports the m5 library so it can get access to the SimObject building stuff and m5.util. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
