Thanks Marc, this is great information.
> question: Should NO_HTML default to true instead of False?
>
Seems reasonable to me.
> > question: Is it necessary to call makeEnv for all 4 binaries when a
> single
> > compile only generates a single binary?
>
I don't see why. Note that it is possible for a single scons invocation to
generate multiple binaries, e.g., you can say:
scons build/ALPHA/gem5.debug build/ALPHA/gem5.opt
(and the regressions certainly take advantage of this, as do I
occasionally).
So we do sometimes need to make multiple makeEnv calls, but we should be
able to figure out which ones are needed and only do the ones that are
necessary for that invocation.
> > question: Should the decider be configured to default to MD5-timestamp?
>
> Should the implicit-cache option be the default behavior?
>
These both seem reasonable to me too. I'm interested to see if there are
any other objections. The scons man page mentions the caveats of these
optimizations, but they seem pretty minor:
Decider(*function*)*env*.Decider(*function*)Specifies that all up-to-date
decisions for targets built through this construction environment will be
handled by the specified *function*. The *function* can be one of the
following strings that specify the type of decision function to be
performed:
*[...]**MD5-timestamp*Specifies that a target shall be considered out of
date and rebuilt if the dependency's content has changed sine the last time
the target was built, except that dependencies with a timestamp that
matches the last time the target was rebuilt will be assumed to be
up-to-date and *not* rebuilt. This provides behavior very similar to the *
MD5* behavior of always checksumming file contents, with an optimization of
not checking the contents of files whose timestamps haven't changed. The
drawback is that SCons will *not* detect if a file's content has changed
but its timestamp is the same, as might happen in an automated script that
runs a build, updates a file, and runs the build again, all within a single
second.
--implicit-cacheCache implicit dependencies. This causes *scons* to use the
implicit (scanned) dependencies from the last time it was run instead of
scanning the files for implicit dependencies. This can significantly speed
up SCons, but with the following limitations:*scons* will not detect
changes to implicit dependency search paths (e.g. *CPPPATH*, *LIBPATH*)
that would ordinarily cause different versions of same-named files to be
used.*scons* will miss changes in the implicit dependencies in cases where
a new implicit dependency is added earlier in the implicit dependency
search path (e.g. *CPPPATH*,*LIBPATH*) than a current implicit dependency
with the same name.
> > question: Can anything else be done to speed up the gem5 build?
>
I don't know, but this seems like a good start... thanks again!
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
