If you give this a try, there are two approaches that might help. First, you could make generating the file that embeds the tip information part of linking the final binary. Then, you'd update it every time you really rebuilt, but you'd only do it when you were rebuilding for some other reason. The contents of that file wouldn't be updated otherwise, so they'd never make anything else out of date.
Second, I'm reading a book all about build systems, and it mentioned that scons has an Ignore() builder which is the opposite of the Depends() builder in that it cuts links in the dependency graph. You could always generate new tip information, but cut the link so it won't trigger a full rebuild on its own. Like before, it would still be incorporated if one happened for another reason. In both of these approaches, the revision information could end up being "stale" if something other than the binary was updated and it played into whatever you were doing. For instance, if you updated configs but didn't touch anything compiled, the revision would reflect the last time gem5.whatever was built, not the revision your configs were at. That could be an important difference. One possible solution could be to embed the revision the binary was built at and to have it also figure out the revision at run time. They would usually be the same, but then you could see both and still save the spurious rebuilds. Gabe On 06/22/11 13:55, Lisa Hsu wrote: > I can give it a shot. Not able to provide an ETA just yet. > > Lisa > > On Wed, Jun 22, 2011 at 1:27 PM, nathan binkert <[email protected]> wrote: > >>> I like Nate's date.cc idea... basically that says whenever you build a >>> binary, stick the current info in, but just because the info has >>> changed that's not sufficient reason to consider the binary out of >>> date. That's the same policy we use wrt the date and time. >> Actually, I took a quick look and I'm not sure why date.cc works. It >> explicitly depends on all other cc files which is why it is rebuilt, >> but I'm not sure why the date change itself doesn't trigger a rebuild. >> It could be because __DATE__ is simply an implicit variable and the >> SCons scanner doesn't see any input changes and never scans the file >> again after the first time. >> >> We could add the hg revision to date.cc (and pass it in via a #define) >> and perhaps use the Ignore() directive on it? >> >> Lisa, want to give it a shot? >> >> Nate >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
