Date: Tue, 27 Aug 2024 17:51:51 +0100
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]> 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]>
> *Sent:* Tuesday, August 27, 2024 5:34:42 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Tiago Freire <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]> 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_[hidden]> on behalf
>> of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>> *Sent:* Tuesday, August 27, 2024 4:01:08 PM
>> *To:* Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>> *Cc:* Jeremy Rifkin <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_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>
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]> 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]>
> *Sent:* Tuesday, August 27, 2024 5:34:42 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Tiago Freire <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]> 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_[hidden]> on behalf
>> of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>> *Sent:* Tuesday, August 27, 2024 4:01:08 PM
>> *To:* Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
>> *Cc:* Jeremy Rifkin <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_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>
Received on 2024-08-27 16:52:05