Date: Thu, 1 Aug 2019 17:26:07 +0200
Ben Boeckel via SG15 <sg15_at_[hidden]> writes:
> Build tools don't generally offer a hook to place a "is this different?"
> function in the build graph.
Some modern build systems support custom per-target out-of-date'ness
criteria. For example, in build2 we use a hash of pp-tokens (including
their line/column numbers) to implement ignorable change detection for
C/C++ compilation. So, at least in our case, it would be pretty easy
to skip recompilation of BMI consumers if the compiler provided a
suitable indication (e.g., a hash).
However, doing this depending on who is asking (consuming) will
definitely be trickier and I am not sure worth the extra complexity.
I think the bulk of the unnecessary recompilations will come from
modifying implementation details (e.g., non-inline function bodies).
And that hash idea would have worked except for the pesky line/column
numbers. So it seems like the best solution is to keep one's
implementation details in module implementation units.
> Build tools don't generally offer a hook to place a "is this different?"
> function in the build graph.
Some modern build systems support custom per-target out-of-date'ness
criteria. For example, in build2 we use a hash of pp-tokens (including
their line/column numbers) to implement ignorable change detection for
C/C++ compilation. So, at least in our case, it would be pretty easy
to skip recompilation of BMI consumers if the compiler provided a
suitable indication (e.g., a hash).
However, doing this depending on who is asking (consuming) will
definitely be trickier and I am not sure worth the extra complexity.
I think the bulk of the unnecessary recompilations will come from
modifying implementation details (e.g., non-inline function bodies).
And that hash idea would have worked except for the pesky line/column
numbers. So it seems like the best solution is to keep one's
implementation details in module implementation units.
Received on 2019-08-01 10:28:11