Date: Wed, 31 Jul 2019 17:44:49 -0400
On 18/07/2019 17.22, David Blaikie via SG15 wrote:
> On 18/07/2019 17.13, Olga Arkhipova via SG15 wrote:> Geraldo and I assumed that compilers and build systems will be able
>> to detect somehow that adding, say, a comment to a module source
>> should not cause rebuild of all components which depend on this
>> module.
>>
>> Nathan and Gaby pointed out that currently built modules contain
>> locations (line/pos I assume) of the declarations in the source
>> file(s), so pretty much any change in the module sources and
>> dependencies (except maybe very trivial ones) will produce a
>> different CMI.
This sounds like the same problem as "don't rebuild libbar, which
depends on libfoo, if libfoo did not change". In that case, if libfoo.so
contains e.g. line number information, too bad. This in turn suggests a
similar fix: keep line number information and symbolic code in separate
files, with consumers not depending on the one the former.
(IOW, more or less what Ben said...)
> if a downstream entity has failed to build pre-change, it'd make sense to
> rerun it so the error messages have the correct/up to date line numbers in
> diagnostics, etc
This is a non-issue. If the entity failed to build, its output does not
exist and that edge is still "dirty", so will be rebuilt anyway.
> (you should not show a user any cached diagnostics from
> the old build) - so the file can't be identical... which is going to be
> super tricky for the build system)
That only sounds like a problem for e.g. ccache, and it's not really
hard to address; ccache will have to consider the file with line numbers
as part of its caching.
I don't see what's "super tricky"?
> On 18/07/2019 17.13, Olga Arkhipova via SG15 wrote:> Geraldo and I assumed that compilers and build systems will be able
>> to detect somehow that adding, say, a comment to a module source
>> should not cause rebuild of all components which depend on this
>> module.
>>
>> Nathan and Gaby pointed out that currently built modules contain
>> locations (line/pos I assume) of the declarations in the source
>> file(s), so pretty much any change in the module sources and
>> dependencies (except maybe very trivial ones) will produce a
>> different CMI.
This sounds like the same problem as "don't rebuild libbar, which
depends on libfoo, if libfoo did not change". In that case, if libfoo.so
contains e.g. line number information, too bad. This in turn suggests a
similar fix: keep line number information and symbolic code in separate
files, with consumers not depending on the one the former.
(IOW, more or less what Ben said...)
> if a downstream entity has failed to build pre-change, it'd make sense to
> rerun it so the error messages have the correct/up to date line numbers in
> diagnostics, etc
This is a non-issue. If the entity failed to build, its output does not
exist and that edge is still "dirty", so will be rebuilt anyway.
> (you should not show a user any cached diagnostics from
> the old build) - so the file can't be identical... which is going to be
> super tricky for the build system)
That only sounds like a problem for e.g. ccache, and it's not really
hard to address; ccache will have to consider the file with line numbers
as part of its caching.
I don't see what's "super tricky"?
-- Matthew
Received on 2019-07-31 16:46:49