>
> FYI, the size of the environment block is part of the same limit that
> applies
> to the command-line. You gain a little by using an environment variable
> for
> all paths instead of a command-line option per path (9 bytes,
> specifically, on
> 64-bit architectures, for the one pointer and the "-I", minus one for a
> delimiter). But if you're running out of space, you're likely to get one
> or
> two more paths with the environment before running out again. Then you add
> the
> problem of having to escape paths containing the delimiter.
>


> With a response file, the delimiter is a newline (which is much less
> likely to
> be used than a colon) and has effectively unlimited size.


Did not realise that, still if you're hitting the limits of the environment
then you're including WAY too much. At that point it's better to get a
framework like qt to handle most of the common stuff and customise *only
where absolutely needed*

On Mon, 2 Sept 2024 at 17:57, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Monday 2 September 2024 05:24:29 GMT-7 Tiago Freire via Std-Proposals
> wrote:
> > I have given you a detailed explanation of the minimum set of complexity
> > that is required of a project to even hit such a problem. And have showed
> > you how that minimum set must include doing things that are considered
> bad
> > practice.
>
> Bad practice or not, they exist.
>
> Here's a simple one that has one such bad practice: vendoring content.
>
> I have a project that has two vendored libraries I need, and one of them
> vendors the other one to. We can call them libpng and zlib, or oneDNN and
> Xbyak, or some other pair.
>
> if, during the compilation of one of my files, both sets of headers are
> found
> by -I options and at least one copy uses #pragma once, my build will fail.
>
> I could solve the problem with this other bad practice: using the vendored
> copy's vendored copy of what I need, but that's yet another bad practice.
> It
> might disappear in a new version, or it might have been only recently
> added.
> My project should not need to know what they're using it for or where such
> headers are in their sources. Not to mention the location inside the
> vendored
> content can change from version to version too.
>
> Worse, the vendoring of the second project may have patched the first's
> copy to
> only supply what they need, in an attempt to minimise namespace pollution,
> meaning I couldn't use it even if I wanted to.
>
> So I have to supply my own copy of the header that I need, which means
> there
> are two files by the same name, supplying mostly or entirely the same
> content,
> but cannot be both included in the same translation unit's compilation.
> Using
> symlinks or hardlinks is not an option, because this project must be
> compiled
> on Windows too.
>
> Now, the correct solution to this is to stop vendoring content. That's
> what
> I've since done to my project in question: I moved all the vendored
> content's
> build to a Docker container and *installed* them system-wide to
> /usr/local,
> with the added benefit of improving my build times (oneDNN and OpenBLAS
> are not
> trivial to build). But this is not an option that will be readily received
> by
> other projects, because vendoring content is too convenient.
>
> And I really don't think the C++ language could afford to mandate it
> either.
>
> In case it isn't clear: this happened to me. This is a first-person
> relating of
> the problem and no strange filesystems were harmed in the process.
> Fortunately,
> in our case, it broke the build for the developer who attempted to import
> the
> third-party library. He did need to ask me for help because the error
> messages
> weren't clear (I applied my rule of thumb "when the error message makes no
> sense, look at the preprocessor output"). I don't remember exactly which
> vendored content it was -- I thought it was Xbyak+oneDNN, but their
> header[1]
> has had include guards since "first commit". I may be mis-remembering some
> other details too.
>
> [1] https://github.com/herumi/xbyak/blob/master/xbyak/xbyak.h
> --
> 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
>