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.
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.
Best,
Bjoern
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.