From: Olga Arkhipova To: Nathan Sidwell , "Hernandez, Gerardo" , Gabriel Dos Reis , Cameron DaCamara Subject: Re: Feedback of P1788R0 Thread-Topic: Feedback of P1788R0 Thread-Index: AQHVOmxW/kl3KBLM3UqcT4i2eHjn6KbLcT4wgAR8z4CAABMp3A== Date: Thu, 18 Jul 2019 09:21:19 +0000 Message-ID: References: <1563123051369.48116@grassvalley.com> ,<2e29ca35-c1a9-de27-e48b-e5f96658742e@acm.org> In-Reply-To: <2e29ca35-c1a9-de27-e48b-e5f96658742e@acm.org> Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-exchange-organization-originalclientipaddress: 62.153.214.124 x-ms-exchange-organization-originalserveripaddress: 2603:10b6:3:a5::7 x-ms-exchange-organization-submissionquotaskipped: False msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=olgaark@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-07-18T09:21:13.5480636Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=c44afc54-ab85-41e7-b929-7e7070e2dbd2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic Content-Type: multipart/alternative; boundary="_000_DM5PR21MB07805B29D6A42B5C84F0DEF4BCC80DM5PR21MB0780namp_" MIME-Version: 1.0 --_000_DM5PR21MB07805B29D6A42B5C84F0DEF4BCC80DM5PR21MB0780namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nathan, My assumption came from the fact that MSVC does this for implibs and winmds= , i.e. the outputs which are often used by other components are not updated= during build (i.e. they don't change their file timestamp) if their conten= t is not changed. To my knowledge, compiler always compiles the files (and updates OBJ) and l= inker always does all the work, but then compares the new output with the e= xisting file and if the same, does not override it. This way the dependent = components don't "feel" they need to be rebuilt without build system storin= g and checking file hashes, so even simple build system's incremental build= works without causing (often long) chain rebuild for the changes not affec= ting public surface (at least most of them). If we cannot do the same for C= MIs, especially if they actually change even if public surface does not (so= hashes will not help), we have a problem. Can you give me an example of the "essential metadata" you are talking abou= t? Thanks, Olga _____ From: Nathan Sidwell on behalf of Nathan Sidwell= Sent: Thursday, July 18, 2019 08:24 To: Olga Arkhipova; Hernandez, Gerardo Subject: Re: Feedback of P1788R0 hi Olga, On 7/17/19 11:03 PM, Olga Arkhipova wrote: > The assumption I had was that BMIs will not be overridden during an incre= mental > build (i.e. when outputs already exist from a previous build) if their co= ntent > is not changed, similarly to other outputs a compiler produces like, say, > implibs for dlls. I also assumed that this is up to the compilers how the= y do it > as only the compiler can see that the public surface is not changed when = sources > are changed. While this is theoretically possible, it's probably not worth the effort. T= he CMI will contain location information (so that diagnostics can be emitted b= y importer's erroreous use), and that of course will change on line insertion= s and deletions, at minimum. So, although the declarations might be quite stable, essential metadata will not be. It's probably expensive to compute 'is-same= ', without actually generating it. We don't have the same request for sameness detection on object files (but they're not inputs to another source compilation). nathan -- Nathan Sidwell --_000_DM5PR21MB07805B29D6A42B5C84F0DEF4BCC80DM5PR21MB0780namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nathan,

My assumption came from the fact that MSVC does this= for implibs and winmds, i.e. the outputs which are often used by other com= ponents are not updated during build (i.e. they don’t change their fi= le timestamp) if their content is not changed.

 

To my knowledge, compiler always compiles the files = (and updates OBJ) and linker always does all the work, but then compares th= e new output with the existing file and if the same, does not override it. = This way the dependent components don’t “feel” they need to be rebuilt without build syste= m storing and checking file hashes, so even simple build system’s inc= remental build works without causing (often long) chain rebuild for the cha= nges not affecting public surface (at least most of them). If we cannot do the same for CMIs, especially if they actually change even= if public surface does not (so hashes will not help), we have a problem.

 

Can you give me an example of the “essential m= etadata” you are talking about?

 

Thanks,

Olga

 

 

From: Nathan Sidwell <nathanmsidwell@gmail.com> on = behalf of Nathan Sidwell <nathan@acm.org>
Sent: Thursday, July 18, 2019 08:24
To: Olga Arkhipova; Hernandez, Gerardo
Subject: Re: Feedback of P1788R0

 =

hi Olga,

On 7/17/19 11:03 PM, Olga Arkhipova wrote:

> The assumption I had was that BMIs will not be overridden during an in= cremental
> build (i.e. when outputs already exist from a previous build) if their= content
> is not changed, similarly to other outputs a compiler produces like, s= ay,
> implibs for dlls. I also assumed that this is up to the compilers how = they do it
> as only the compiler can see that the public surface is not changed wh= en sources
> are changed.

While this is theoretically possible, it's probably not worth the effort. T= he
CMI will contain location information (so that diagnostics can be emitted b= y
importer's erroreous use), and that of course will change on line insertion= s and
deletions, at minimum. So, although the declarations might be quite stable,=
essential metadata will not be. It's probably expensive to compute 'is-same= ',
without actually generating it.

We don't have the same request for sameness detection on object files (but =
they're not inputs to another source compilation).

nathan
--
Nathan Sidwell

--_000_DM5PR21MB07805B29D6A42B5C84F0DEF4BCC80DM5PR21MB0780namp_--