rebuilt 1 .cxx, linked 184 libraries

[Lubos Lunak]

On Thursday 04 of April 2013, Michael Stahl wrote:
> On 04/04/13 20:47, Bjoern Michaelsen wrote:
> > On Thu, Apr 04, 2013 at 02:11:35PM -0400, Terrence Enger wrote:
> >> I just changed vcl/source/window/builder.cxx and did top-level make.
> >> The make had 184 [build LNK] steps.  Is this to be expected?
> >
> > We could evade that with build order only deps (signified :|, see
> > http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html
> > ) and with (simplified):
> >
> >  $(call gb_Library_get_target,a) :| $(call gb_Library_get_target,b)
> >  $(call gb_Library_get_target,a) : $(call
> > gb_Library_get_headers_target,b) $(call gb_Library_get_target,b) : some
> > object from lib b : some cxx from lib b
> >
> > This would make library a being rebuild only if one of the 'public',
> > delivered headers of library b changed but not otherwise. And it would
> > make sure, that if both library a and b need to be rebuild, a will always
> > be rebuild after b.
>
> but it has the significant problem that you can remove implementations
> of the public API of library a without noticing it (which you would when
> library b fails to link), thus making incremental builds unsound.

 Significant? That scenario is already broken on its own. If a library changes 
its API, that means its headers need to change as well, thus the dependent 
library will eventually need to be relinked. If that's not the case, the 
change itself is broken.

 Moreover, this scenario is nowadays still somewhat likely, if one rebuild 
just a specific module, instead running toplevel make - how many of us do 
that after each change? I for sure don't, and won't as long as it takes that 
much time it takes.

 I actually agree with Terence. If a library changes, its dependent libraries 
should change and thus relink even without having .so <- .so dependencies. I 
do not see a good use case where this would be a problem.

-- 
 Lubos Lunak
 l.lunak at suse.cz