Date: Wed, 8 Jun 2022 17:22:44 +0000
[Steve]
* However, at least on Unix-ey environments, the ability to deliberately shadow headers is very important. That is, being able to interpose the headers for a library, and the library itself, to provide a newer version, or to do development on the library that happens to be on the system already. This sort of environment is somewhat less common on Windows, from what I remember and have seen, unless they're deliberately imitating a unix file hierarchy.
Actually, that need is really not that different from ability to relocate. Shadowing/interposing can be achieved by specifying an alternate header unit map.
-- Gaby
From: Steve Downey <sdowney_at_[hidden]>
Sent: Wednesday, June 8, 2022 8:24 AM
To: ISO C++ Tooling Study Group <sg15_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers
On Wed, Jun 8, 2022 at 12:43 AM Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> 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.
Or the opposite problem with a very few -I paths with 100K files in each of them. Mounted as NFS, of course.
However, at least on Unix-ey environments, the ability to deliberately shadow headers is very important. That is, being able to interpose the headers for a library, and the library itself, to provide a newer version, or to do development on the library that happens to be on the system already. This sort of environment is somewhat less common on Windows, from what I remember and have seen, unless they're deliberately imitating a unix file hierarchy.
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).
-- Gaby
* However, at least on Unix-ey environments, the ability to deliberately shadow headers is very important. That is, being able to interpose the headers for a library, and the library itself, to provide a newer version, or to do development on the library that happens to be on the system already. This sort of environment is somewhat less common on Windows, from what I remember and have seen, unless they're deliberately imitating a unix file hierarchy.
Actually, that need is really not that different from ability to relocate. Shadowing/interposing can be achieved by specifying an alternate header unit map.
-- Gaby
From: Steve Downey <sdowney_at_[hidden]>
Sent: Wednesday, June 8, 2022 8:24 AM
To: ISO C++ Tooling Study Group <sg15_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>; Gabriel Dos Reis <gdr_at_[hidden]>
Subject: Re: [SG15] "logical name" of importable headers
On Wed, Jun 8, 2022 at 12:43 AM Gabriel Dos Reis via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> 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.
Or the opposite problem with a very few -I paths with 100K files in each of them. Mounted as NFS, of course.
However, at least on Unix-ey environments, the ability to deliberately shadow headers is very important. That is, being able to interpose the headers for a library, and the library itself, to provide a newer version, or to do development on the library that happens to be on the system already. This sort of environment is somewhat less common on Windows, from what I remember and have seen, unless they're deliberately imitating a unix file hierarchy.
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).
-- Gaby
Received on 2022-06-08 17:22:47