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.   (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] <mailto: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.