> And what would that tell Gašper? That he should tell his company to stop doing
business because C++ no longer supports his environment? Or possibly invest
hundreds of thousands of dollars (or more) on massive infrastructure upgrades
to cache all the files locally without having to have FUSE?

Well, the failure mode of a filesystem-based definition in this case
is a header being duplicated across multiple mounts, with different
#includes resolving to paths on different mounts, resulting in them
being #included multiple times. Depending on how the FUSE mounts are
set up, maybe this sort of header duplication can be avoided.
Alternatively, e.g. in the case of libraries, a qualified include
guard should probably be preferred. Alternatively, maybe this is a
tooling problem and generating forwarding headers as Gašper mentioned
is the right solution.

Does that seem reasonable?

It would be helpful to hear more from Gašper on this, too.

Jeremy

On Thu, Aug 29, 2024 at 8:50 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thursday 29 August 2024 16:29:31 GMT-7 Jeremy Rifkin via Std-Proposals
> wrote:
> > In case it's not already abundantly clear: A content-based definition
> > is the only way to make #pragma once work for a setup like yours with
> > multiple mounts. But perhaps such a feature shouldn't bend over
> > backwards to support such a case.
>
> And what would that tell Gašper? That he should tell his company to stop doing
> business because C++ no longer supports his environment? Or possibly invest
> hundreds of thousands of dollars (or more) on massive infrastructure upgrades
> to cache all the files locally without having to have FUSE?
>
> As I said in the other email, #pragma once transfers the problem from the
> author of the code to the user of the code.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals