On Wed, Jun 8, 2022 at 12:43 AM Gabriel Dos Reis via SG15 <
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
>
>
>