You are to resolve an include file and yet you are not able to tell where the file comes from. Seems like your tool has a problem. But that's not my concern.
My concern is, why should I be penalized because you have that problem?

________________________________
From: Gašper Ažman <gasper.azman_at_[hidden]>
Sent: Tuesday, August 27, 2024 6:52:07 PM
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden] <std-proposals_at_[hidden]socpp.org>
Subject: Re: [std-proposals] Revising #pragma once

My project doesn't "have problems".

When you're compiling on a compute-farm and you're mounting immutable object stores for your builds because otherwise your build literally consumes 10x the I/O, then your local include of #include "siblingheader.h" has a fundamentally different include path than my #include "3p/yourlib/siblingheader.h", and the compiler will get the 3p one through a sandbox (a standard bazel feature) and the sibling through a direct directory scan. It's a matter of how you do a syscall.

This is an incredibly engineered build system, which is *still* a far cry from being as complex as google's codefs, but please don't tell me how using fuse to save on I/O is somehow unreasonable and I should not be using _features c++ literally guarantees me because they are standard_.

Some of us spend 7 or 8 digits a year on compute and I/O for builds. Literally, don't try to teach me my job.

On Tue, Aug 27, 2024 at 5:45 PM Tiago Freire <tmiguelf_at_[hidden]<mailto:tmiguelf_at_[hidden]>> wrote:
I agree that pragma once should mean same file and not file with same bits.

But I disagree on everything else.
I used pragma once exclusively on all my libraries quite successfully, they are well organized and no such confusion could occur by design, "as a well orchestrated build should".

If you are in a situation where this causes problems, either by having multiple copies of the same library or by using symbolic or hard links, and they all end up on the same include stack. Well... then don't do that then! Seems like a you problem.
I'm not trying to dunk on a "serious project" with a "quite amateurish build execution", I'm pretty sure there are legacy reasons as to why your project ended up in this awkward situation, my advice is just don't use it for your project then.

There's no reason why everyone else has to code like its 1990 just because your project got problems.


My 2c

________________________________
From: Gašper Ažman <gasper.azman_at_[hidden]<mailto:gasper.azman_at_[hidden]>>
Sent: Tuesday, August 27, 2024 5:34:42 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Tiago Freire <tmiguelf_at_hotmail.com<mailto:tmiguelf_at_[hidden]>>
Subject: Re: [std-proposals] Revising #pragma once

#pragma once is unimplementable.

That's because it doesn't mean "don't include a file with the same bytes", it means "don't include the same file". And the second you have the same file accessible through two separate fuse mountpoints, no amount of stat() will help you identify it's the same file.

We hit this in our build-farms all the time, I had to write tooling to kill it.

Don't make me explain this in-committee, again.

On Tue, Aug 27, 2024 at 4:32 PM Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
I like pragma once, should be standardized, but the problem is in the details of the wording.

I know that the paper acknowledges that some compiler issues a warning if they appear in the source file, and that the paper doesn't advocate for the warning either way. But the note seems to suggest otherwise.
It would be best if the standard had no notion of what a source file is, and you should remove the note that a compiler could issue a warning, let that just be a vendor detail.

The description of how the directive should behave isn't the best, describing in in terms of an ifdef block is not good.


________________________________
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org<mailto:std-proposals-bounces_at_[hidden]>> on behalf of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Sent: Tuesday, August 27, 2024 4:01:08 PM
To: Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Cc: Jeremy Rifkin <rifkin.jer_at_[hidden]<mailto:rifkin.jer_at_[hidden]>>
Subject: [std-proposals] Revising #pragma once

Hi,
I have drafted a proposal for standardizing #pragma once. This has been previously proposed a few years ago and I recognize that on top of being difficult to standardize, existing opinions on this topic may render the paper dead on arrival. However, due to its widespread nature and concerns about portability contributing to it not being used more I think it's worth revisiting. I have uploaded the first draft at: https://jeremy-rifkin.github.io/cpp-proposals/drafts/pragma-once-draft-1.html.

Cheers,
Jeremy
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals