Date: Wed, 31 Jul 2019 23:30:02 +0000
Yes, having more than one file for a built module is definitely an option.
If we look at other languages - c#, for instance, produces a "regular" binary (containing definitions, implementations and whatever else) and a special "reference only" binary, containing only public declarations. The first one is updated every time it builds, the second one only if public surface is changing.
For stale locations in warnings - I don't think this is a big problem because it can happen only for sources which import the module (not the module source itself, as it will always built when changed) and only when this source was successfully compiled before which means that the warnings were happily ignored. If they are important, people usually set "treat warnings as errors". And if there were errors, the source will be rebuilt anyway.
In VS IDE (and msbuild in general) the ignored warnings are currently lost anyway in the subsequent incremental builds and I remember only one complain about that. The complains about "overbuild" is way more numerous and loud.
Anyway, if we have an ability to rebuild dependencies only for public module changes we also can have an option to "always build" if this is important for somebody. Currently, we force everybody to pay the price for this correctness and I this does not look right to me.
Thanks,
Olga
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Matthew Woehlke via SG15
Sent: Wednesday, July 31, 2019 2:45 PM
To: sg15_at_[hidden]
Cc: Matthew Woehlke <mwoehlke.floss_at_[hidden]>; Hernandez, Gerardo <Gerardo.Hernandez_at_[hidden]>; blopes_at_[hidden]; Gor Nishanov <gorn_at_[hidden]>; Cameron DaCamara <Cameron.DaCamara_at_[hidden]>; nathan_at_[hidden]
Subject: Re: [SG15] Will any change in a module source or dependencies cause change in the public/reachable surface of the built module?
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"?
If we look at other languages - c#, for instance, produces a "regular" binary (containing definitions, implementations and whatever else) and a special "reference only" binary, containing only public declarations. The first one is updated every time it builds, the second one only if public surface is changing.
For stale locations in warnings - I don't think this is a big problem because it can happen only for sources which import the module (not the module source itself, as it will always built when changed) and only when this source was successfully compiled before which means that the warnings were happily ignored. If they are important, people usually set "treat warnings as errors". And if there were errors, the source will be rebuilt anyway.
In VS IDE (and msbuild in general) the ignored warnings are currently lost anyway in the subsequent incremental builds and I remember only one complain about that. The complains about "overbuild" is way more numerous and loud.
Anyway, if we have an ability to rebuild dependencies only for public module changes we also can have an option to "always build" if this is important for somebody. Currently, we force everybody to pay the price for this correctness and I this does not look right to me.
Thanks,
Olga
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Matthew Woehlke via SG15
Sent: Wednesday, July 31, 2019 2:45 PM
To: sg15_at_[hidden]
Cc: Matthew Woehlke <mwoehlke.floss_at_[hidden]>; Hernandez, Gerardo <Gerardo.Hernandez_at_[hidden]>; blopes_at_[hidden]; Gor Nishanov <gorn_at_[hidden]>; Cameron DaCamara <Cameron.DaCamara_at_[hidden]>; nathan_at_[hidden]
Subject: Re: [SG15] Will any change in a module source or dependencies cause change in the public/reachable surface of the built module?
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"?
-- Matthew _______________________________________________ SG15 mailing list SG15_at_[hidden] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=02%7C01%7Colgaark%40microsoft.com%7C291c10d25362404749aa08d7160052ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002062959463388&sdata=4DJD7wX%2FMBKwhR17zu6W15dZ3wEQkf3Jym6l1%2F%2BWEgU%3D&reserved=0
Received on 2019-07-31 18:32:01