Date: Wed, 8 Jun 2022 04:43:43 +0000
I have a few reservations:
1. Trying to resolve the header file before consulting the header unit map to BMI involves poking the filesystem, which we have empirically found to be performance bottleneck (one of the reasons it is good to move away from the whole include path story), even with SSD on "fast" filesystems. It is common to have hundreds of '-I' supplied by the build at scale, and the one that is relevant is at the very end.
2. Resolving to absolute path defeats ability to relocate - I know not every one here cares, but people in my user population do care about ability to relocate BMIs. (we have done lot of shenanigans with __FILE__ and friends, but it is better not to create the problem in the first place).
-- Gaby
From: Tom Honermann <tom_at_[hidden]>
Sent: Tuesday, June 7, 2022 9:17 PM
To: sg15_at_[hidden]; Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Daniel Ruoso <daniel_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers
On 6/6/22 6:26 PM, Daniel Ruoso via SG15 wrote:
Actually, on a second thought, there is one thing that I think is still problematic.
When the compiler is not replacing includes by imports, it would still result in different headers, which I think is going to generate a lot of confusion.
I'd advocate for giving the compiler the tuple with the token, the header file and the BMI. That way it would always use the same header, even if not replacing the include by an import.
I agree with making this more robust.
Perhaps a slight tweak: supply the compiler with the token and BMI. if the token contains a relative path, try to resolve it to an absolute path via the include paths. If a match is found, then substitute the constructed absolute path as if it had been explicitly provided. If a match is not found, then use the BMI only when a matching token is presented in a #include or import directive. The former rule strengthens the #include vs import consistency while the second rule retains an option to migrate away from include paths.
Tom.
Daniel
On Mon, Jun 6, 2022, 17:21 Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>> wrote:
Great. So that matches exactly what I was advocating for.
I'll try to write a paper summarizing all this, and advocating for that approach on all implementations.
On Mon, Jun 6, 2022, 17:19 Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
[Daniel]
> I may have misunderstood. When the following argument is given:
>
> /headerUnit:angle foo.h=/some/foo.h.ifc
>
> Does that mean MSVC will not perform a lookup in the include
> directories and will just apply that for both `#include <foo.h>` and
> `import <foo.h>`? Even if no there was no foo.h in any of the include
> directories?
No, MSVC does not look up via include directories before applying the mapping of
import <foo.h>;
to the corresponding IFC. Additionally, if you have /translateInclude and
#include <foo.h>;
it will not look up in the include directory.
However, if you specify
/headerUnit /some/absolute/path/to/foo.h=/some/foo.h.ifc
and you have
#include <foo.h>
it would first look up <foo.h> via the include directories. If the selected source file happens to match the mapping specified then it will the IFC.
-- Gaby
-----Original Message-----
From: Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>>
Sent: Monday, June 6, 2022 1:15 PM
To: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Cc: sg15_at_[hidden]<mailto:sg15_at_[hidden]>; Boris Kolpackov <boris_at_[hidden]<mailto:boris_at_[hidden]>>
Subject: Re: [SG15] "logical name" of importable headers
Em seg., 6 de jun. de 2022 ās 15:21, Gabriel Dos Reis
<gdr_at_[hidden]<mailto:gdr_at_[hidden]>> escreveu:
> > Specifically, the input to the compiler would be a map from the token
> > used after include or import to the header file and the bmi for that
> > header unit.
> I think is what MSVC does... no?
I may have misunderstood. When the following argument is given:
/headerUnit:angle foo.h=/some/foo.h.ifc
Does that mean MSVC will not perform a lookup in the include
directories and will just apply that for both `#include <foo.h>` and
`import <foo.h>`? Even if no there was no foo.h in any of the include
directories?
Is there ever a situation where the compiler would need the path to
the original header?
daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C895acb9611bc4366d3ec08da4905bb72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637902586219041386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NxGzr03EgQbcFgbAqJXtU6u7MzmM6QOFndBKTgtfn8E%3D&reserved=0>
1. Trying to resolve the header file before consulting the header unit map to BMI involves poking the filesystem, which we have empirically found to be performance bottleneck (one of the reasons it is good to move away from the whole include path story), even with SSD on "fast" filesystems. It is common to have hundreds of '-I' supplied by the build at scale, and the one that is relevant is at the very end.
2. Resolving to absolute path defeats ability to relocate - I know not every one here cares, but people in my user population do care about ability to relocate BMIs. (we have done lot of shenanigans with __FILE__ and friends, but it is better not to create the problem in the first place).
-- Gaby
From: Tom Honermann <tom_at_[hidden]>
Sent: Tuesday, June 7, 2022 9:17 PM
To: sg15_at_[hidden]; Gabriel Dos Reis <gdr_at_[hidden]>
Cc: Daniel Ruoso <daniel_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers
On 6/6/22 6:26 PM, Daniel Ruoso via SG15 wrote:
Actually, on a second thought, there is one thing that I think is still problematic.
When the compiler is not replacing includes by imports, it would still result in different headers, which I think is going to generate a lot of confusion.
I'd advocate for giving the compiler the tuple with the token, the header file and the BMI. That way it would always use the same header, even if not replacing the include by an import.
I agree with making this more robust.
Perhaps a slight tweak: supply the compiler with the token and BMI. if the token contains a relative path, try to resolve it to an absolute path via the include paths. If a match is found, then substitute the constructed absolute path as if it had been explicitly provided. If a match is not found, then use the BMI only when a matching token is presented in a #include or import directive. The former rule strengthens the #include vs import consistency while the second rule retains an option to migrate away from include paths.
Tom.
Daniel
On Mon, Jun 6, 2022, 17:21 Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>> wrote:
Great. So that matches exactly what I was advocating for.
I'll try to write a paper summarizing all this, and advocating for that approach on all implementations.
On Mon, Jun 6, 2022, 17:19 Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
[Daniel]
> I may have misunderstood. When the following argument is given:
>
> /headerUnit:angle foo.h=/some/foo.h.ifc
>
> Does that mean MSVC will not perform a lookup in the include
> directories and will just apply that for both `#include <foo.h>` and
> `import <foo.h>`? Even if no there was no foo.h in any of the include
> directories?
No, MSVC does not look up via include directories before applying the mapping of
import <foo.h>;
to the corresponding IFC. Additionally, if you have /translateInclude and
#include <foo.h>;
it will not look up in the include directory.
However, if you specify
/headerUnit /some/absolute/path/to/foo.h=/some/foo.h.ifc
and you have
#include <foo.h>
it would first look up <foo.h> via the include directories. If the selected source file happens to match the mapping specified then it will the IFC.
-- Gaby
-----Original Message-----
From: Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>>
Sent: Monday, June 6, 2022 1:15 PM
To: Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>>
Cc: sg15_at_[hidden]<mailto:sg15_at_[hidden]>; Boris Kolpackov <boris_at_[hidden]<mailto:boris_at_[hidden]>>
Subject: Re: [SG15] "logical name" of importable headers
Em seg., 6 de jun. de 2022 ās 15:21, Gabriel Dos Reis
<gdr_at_[hidden]<mailto:gdr_at_[hidden]>> escreveu:
> > Specifically, the input to the compiler would be a map from the token
> > used after include or import to the header file and the bmi for that
> > header unit.
> I think is what MSVC does... no?
I may have misunderstood. When the following argument is given:
/headerUnit:angle foo.h=/some/foo.h.ifc
Does that mean MSVC will not perform a lookup in the include
directories and will just apply that for both `#include <foo.h>` and
`import <foo.h>`? Even if no there was no foo.h in any of the include
directories?
Is there ever a situation where the compiler would need the path to
the original header?
daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C895acb9611bc4366d3ec08da4905bb72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637902586219041386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NxGzr03EgQbcFgbAqJXtU6u7MzmM6QOFndBKTgtfn8E%3D&reserved=0>
Received on 2022-06-08 04:43:46