Bernhard Voelker <[email protected]> writes:
> Technically it doesn't seem to matter [1], because we're using -I which <...>
> also searches.
> Still there might be a case where the search order might be messed and the
> compiler would find the system library before the replacement one from
> gnulib, no?
>
> [1] https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
You are correct that it does not matter since we use '-I' to include
the source directory, gnulib, etc:
$ grep '^AM_CPPFLAGS' Makefile.am
AM_CPPFLAGS = -Ilib -I$(top_srcdir)/lib -Isrc -I$(top_srcdir)/src
That ensures we get Gnulib headers and local headers before the system
ones.
If you assume #include_next support then you don't have to worry about
overlapping standardized names. Using it would allow you to include the
next occurrence of the header, e.g. the one installed on the system.
If you don't have #include_next support, then you can try to use the
absolute file name of the system header. I think that is how
gl_NEXT_HEADERS supports old compilers.v
> Yet I'm not sure what they mean by "quote directories":
>
> It searches [...] first in the directory containing the current file,
> then in the quote directories and then [...]
> ______________^^^^^^^^^^^^^^^^^
I am leaning towards that being a typo of "quoted directories". But
maybe they meant to describe the quote character.
> So is this only a matter of consistency, or do we have a potential issue?
Consistency and personal taste, IMO.
I typically use #include <...> for system headers or things we can
reasonably assume are a system package (e.g. openssl/openssl.h,
curl/curl.h, etc.) For files in the project or vendored dependencies I
use #include "...".
But based on Paul's commit he has a different way of doing things than I
do.
Collin
