Date: Tue, 27 Aug 2024 12:02:59 -0500
The C++ ecosystem is diverse with many approaches to building. As far as
this paper is concerned, they are all equally legitimate. My goal in this
paper is to not break any existing workflows, and only make things more
robust and portable.
Jeremy
On Tue, Aug 27, 2024 at 11:52 Gašper Ažman via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
this paper is concerned, they are all equally legitimate. My goal in this
paper is to not break any existing workflows, and only make things more
robust and portable.
Jeremy
On Tue, Aug 27, 2024 at 11:52 Gašper Ažman via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-08-27 17:03:14