On Mon, Sep 2, 2024, 09:52 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi Gašper,
>
>
>
> perhaps my answer was too fast.
>
>
>
> I was trying to go a third way:
>
> Neither content nor local file identity, but using the path given in the
> #include files.
>
>
>
> Difficulties arise from the facts
>
> - that libraries have several entry points for their includes, possibly
> in subdirectories.
>
> - that -I include directories may point to one or several libraries
>
> - that some libraries would need several -I parameters, e.g. for
> sub-components or plugins
>
>
>
> Perhaps a working solution would be to create a #once only working for
> #include "".
>
> After including a library with a search path with <>, all subsequent
> includes with "" are seen relative to the current file.
>

That would change what #include "" means.

#include <> is a carve out for the standard library and os-includes,
everything else is supposed to use "", as far as the standard is concerned.
You shouldn't include boost libs with <>, for instance.

The fact that everyone breaks this rule to some (and wildly different
extents) is also a confounding factor.

You get there by looking at cpp.include#note-1 , cpp.include#2,
using.headers 1,2,3 and headers#1, which defines every header that exists,
and it basically is just "whatever the implementation says is a header".
You don't get to write headers, basically, as per the standard, so no
library other than platform libraries (c, c++, posix, etc) gets to have
"headers" and therefore don't get to have <>-includes. And yes, rule is so
often broken it's not a rule in practice, but this is the standard so we
kind have to pay lip service to that.


Could we please all accept that:

- files do not have canonical names on a filesystem (sandboxes, symlinks,
hard links, mount points)
- files do not have canonical inodes on a filesystem (reuse of inodes
between different files, different inode every time a file is opened)

This is not changing. This is unimplementable.


>
> (Some compilers provide more complicated options to also extend a search
> path for "" or do so with the paths of all previously included files, but
> those extended lookup paths are not standard.)
>
>
>
> With those files at least it should be possible to rely solely on the
> paths provided in the #include "" directives.
>
>
>
>
>
> What to do with
>
>
>
> main.cpp
>
> #include <mylib/librarydefs.h>
>
> #include <mylib/constants.h>
>
> librarydefs.h:
>
> #include "constants.h"
>
>
>
> librarytemplates.h:
>
> #include "constants.h"
>
>
>
> constants.h:
> #once
>
>
>
>
>
> We would have to know that both includes in main point to the same library.
>
>
>
> That could get more difficult with
>
>
>
> -I /includes/alllibs -I /specialincludes/mylibplugins
>
>
>
> On the other hand, #include "" probably would not work now either between
> those subcomponents of the library.
>
>
>
> So we could limit #once to work only within one -I path (or of course in
> the cpp file, as long as #include "" is used locally)
>
>
>
>
>
>
>
> Not sure, if it is worth it, as it is only a partly solution (only
> #include "") and is different from all the existing #pragma once
> implementations. And perhaps I have not seen some of the possible pitfalls.
>
>
>
>
>
> Best,
>
> Sebastian
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Gašper Ažman <gasper.azman_at_[hidden]>
> *Gesendet:* So 01.09.2024 15:10
> *Betreff:* Re: [std-proposals] Revising #pragma once
> *An:* Std-Proposals <std-proposals_at_[hidden]>;
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
> ... Just so you are aware, we sometimes run over of commandline max length
> because of the number of -I flags. Also note that it's common to have -I
> dir/ -I dir/subdir/ on the commandline. How do you translate that to your
> schema?
>
> On Sun, Sep 1, 2024, 10:42 Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> We established that
>
> - there are situations, two header files in different projects are the
> same, and have to be included twice (master header)
>
> - there are situations, two header files in different projects are the
> same, and have to be included once (zlib.h)
>
>
>
> Path:
>
> Each include is either
>
> - done by <>
>
> - done by "" relative to a different include file or the cpp file
>
>
>
> In the case of <> uniqueness is important to prevent libraries (or their
> headers) to be imported more than once.
>
>
>
> In the case of "" uniqueness, doubled imports within the project should be
> avoided. Circular imports would probably give an error anyway.
>
>
>
>
>
> If we strictly use the path in the C++ files (not the path in the file
> system), we should get
>
>
>
> [<systemheader_filepath>]/["projectheader_filepath"]
>
> with [] for optional
>
> E.g. <mylib/importall.h>/"mylib_internal/types.h"
>
>
>
>
>
> Why is this path not enough?
>
>
>
> The zlib.h case with headers-only libraries?
>
> Those should probably keep symbol-dependent include guards.
>
>
>
> Relying on this path should make once independent of the build environment
> and the storage of the files.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>