rebuilt 1 .cxx, linked 184 libraries

[Michael Stahl]

On 04/04/13 22:28, Bjoern Michaelsen wrote:
> Hi, 
> 
> On Thu, Apr 04, 2013 at 10:04:24PM +0200, Michael Stahl wrote:
>> 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.
> 
> We are not supporting that scenario entirely anyways: If you are evil, you are
> removing a object from a library in a makefile and leaving the headers there
> still, which currently causes no rebuild of the lib and thus lets you commit
> broken state. That could be worked around by depending on the Makefile defining
> the lib (Library_foo.mk) from e.g. the 
> $(call gb_Library_get_headers_target,foo), but we considered that too
> conservative for the average developer build -- whenever you touch that
> makefile adding or removing an object, everything would be rebuild.

this is strictly speaking a bug, and the main problem here is that C++
takes an awful long time to rebuild (otherwise i would have added a
makefile dependency already like i've done for Zip, InstallModule, Help
etc. targets that are quick to rebuild).  hmmm... perhaps it would be
easy and "good enough" to just re-link when the makefile changes

> Note the chromium guys dump the exported symbols and only rebuild deps if that
> changed. We could do the same, but I dont think the added complexity and
> possible loss of robustness of doing this on all platforms is justified by the
> gain.

actually i really like that idea, we should look at doing that some day...

... one other thing i've always dreamed of is to store the commands that
were executed somewhere so we can rebuild files when you edit the
makefile, but only if that actually changes your command line and not if
your change is only for $some-other-platform-or-configuration... iirc
Linux build system does something like that...