On 12/07/09 12:27, bjoern michaelsen - Sun Microsystems - Hamburg
Germany wrote:
On Mon, 07 Dec 2009 11:51:07 +0100
Stephan Bergmann <[email protected]> wrote:
(1) A new file x/z is added to the SCM. A file y/z already exists.
Will all C/C++ files be recompiled that #include "z" and have -Ix
before -Iy on their compiler command lines?
If one regenerates dependencies, yes. The question is if one should do
that on every build by default. I would say no. In any way, it is
entirely possible to do that with little additional effort.
(2) A linker switch is added to a makefile variable X in some file
y. Will all the linker invocations that depend on X, in all the
makefiles that (indirectly) include y be re-done?
Well, all the "build logic" is intended to be kept in a small set of
files in solenv. Of course, every target can depend on those (in
addition to the declarative file describing the library to link),
causing a rebuild when the build system itself changes. Separating
those to a finer granularity (depending on platform, separating linking
and building etc.) is also possible, but might require too much effort
to maintain to be worth it. BTW, this is not to different from the
considerations on implicit dependencies of default_images recently
discussed on [email protected].
The question then is whether the mechanisms needed to implement such a
sound "full dependencies mode" (like always regenerating dependencies
and having dependencies on "solenv files") are worth the added
complexity, given that the time/power consumption advantages of a "full
dependencies mode" rebuild over a complete rebuild will probably be
somewhat smaller than those of an (erroneous, in the general case)
"limited dependencies mode" rebuild over a complete one.
Anyway, my main concern was one of false advertising. Unless we do
offer a "full dependencies mode," one should not claim that the
projected new build system will generally make bisectional bug-hunting
or resync possible without complete rebuilds.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
