On 6/8/22 12:43 AM, Gabriel Dos Reis via SG15 wrote:
>
> 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.
>
I agree the overhead is noticeable.
>
> 1.
>
>
> 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).
>
Can you explain how relocation is defeated? I agree relocation is useful
and should be supported. The approach I had in mind is that compilers
would construct the absolute paths from relative paths supplied on the
compiler command line; they need not be preserved.

Tom.

> 1.
>
> -- 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]> 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]> 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]>
> Sent: Monday, June 6, 2022 1:15 PM
> To: Gabriel Dos Reis <gdr_at_[hidden]>
> Cc: sg15_at_[hidden]; Boris Kolpackov
> <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]> 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]
> 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>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15