If we can't do a scanner, I don't have a huge problem with listing output files explicitly... yea, it's not as elegant, but I don't expect it to change a lot either.
Steve On Feb 2, 2011 2:25 PM, "Gabe Black" <[email protected]> wrote: > On 02/02/11 13:05, nathan binkert wrote: >>> So, one important question apart from actually generating multiple files is >>> how we'd get scons to realize the generated files are dependencies of the >>> original ISA description. The actual dependencies are fairly straight >>> forward to set up, the problem is scons doesn't know what files are going to >>> be generated, so it doesn't know what to make the dependencies between. >> Why doesn't it know what will be generated? How are you intending to >> split up the output files? Is there some way that we can define >> things in such a way that we can build a scanner? > > It wouldn't know because it wouldn't have a list, perse, it would set > things up as it went. I'm not sure exactly -how- it would do that, but I > did a little Googling and didn't find anything for python dependency > scanners so I think it's a hard thing to figure out. Some initial ideas > are to have output objects that describe different sets of files and you > pick one to use, or some language construct that switches to a new set. > I prefer the first since it's more flexible and sticks more with garden > variety python instead of new language features, but the second might be > easier to make a scanner for. > > >>> There's a similar problem I have with the x86 microcode which I "solved" by >>> listing all the microcode files in a huge list in the SConscript file, I >>> believe, but if this is going to be pervasive then we need a less hacky, >>> more automatic system. Any suggestions are welcome. >> We deal with this in SLICC by running SLICC twice, once to generate >> the list of output files, and once to actually generate the files. I >> find that ugly, but it does work. A scanner would be better. > > Yeah, this may just be what we have to do. I don't have a better idea, > although I was hoping somebody would swoop in with one. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
