Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On 09/26/2011 10:01 PM, Bjoern Michaelsen wrote:
On Mon, 26 Sep 2011 21:33:03 +0200
Stephan Bergmann<sbergman@redhat.com>
wrote:

I think its *file based* dependencies that's the problem here -- they
are simply not at the right level of granularity.  (Then again, I'm
not sure there's at all a working theory of making arbitrary changes
to your source tree and then rebuilding everything that needs to be
rebuilt while only rebuilding as little as possible what would not
necessarily need to be rebuilt.)

No need for such theory, as for all practical proposes, there is ccache
doing exactly that (although with a bit of addition IO). As for finer
granularity: With the practical reality of C/C++ with preprocessing,
context sensitive syntax and commandline switches to influence the
compile result there is little hope for such a thing existing _and_ be
reasonably fast (read: orders of magnitude faster than just frigging
compiling it).

"there is ccache doing exactly that": but not everything is being built by the C/C++ compilers...

"finer granularity": I did not mean finer granularity within C/C++ files (so that a changed header does not necessarily cause rebuild of every file including it), but rather within the makefiles themselves (so that a change to one recipe in one makefile would not cause everything to be rebuilt if we had targets depend on the makefiles their recipes come from):

-Stephan

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.