[vlc-devel] [PATCH 4/4] seek config.h include via angled bracket search

Lyndon Brown jnqnfe at gmail.com
Tue Oct 6 20:29:02 CEST 2020

On Tue, 2020-10-06 at 08:33 +0200, Steve Lhomme wrote:
> On 2020-10-04 20:44, Lyndon Brown wrote:
>  > I only just received this email of yours today for some reason,
> even
>  > though it's marked as sent on Friday.
>  >
>  > It would help clarify things for me if you could possibly please
> point
>  > out the bits of the build system that would allow such a thing to
>  > happen.
> I just gave it a try. I put a dummy config.h in my 
> contrib/x86_64-w64-mingw32/include directory with some #error in it.
> "" or <> the result is the same, it's not used. So at least as far
> as 
> clang is concerned it won't be used.

Good :)

> It may also be because we include a lot of folders. Here's an
> example 
> for a module:
> -I.
> -I/mnt/vlc/extras/package/win32/../../../modules
> -I..
> -I/mnt/vlc/extras/package/win32/../../../modules/access
> -I/mnt/vlc/extras/package/win32/../../../modules/codec
> -I/mnt/vlc/extras/package/win32/../../../include
> -I../include
> -I/mnt/build/win64/contrib/x86_64-w64-mingw32/include
> This is called from <build>/modules so -I.. is the path where the
> local 
> config.h is. It comes before the contribs one so it's safe to say it 
> will be picked before contrib ones. The rest in our source tree is
> our 
> responsibility.

That's what I expected would be the case, so great to confirm there's
no issue.

>  > As I said before, my understanding of the difference between
> quoting
>  > and angle brackets is that with quoting, the directory of the file
>  > doing the include is checked first, before falling back to the
> angle
>  > bracket path search.
> It seems more subtle than that and is left to compilers to decide.
> For 
> example in gcc you have this: 
> https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
> "Directories specified with -iquote apply only to the quote form of
> the 
> directive, #include "file". Directories specified with -I, -isystem,
> or 
> -idirafter apply to lookup for both the #include "file" and #include 
> <file> directives."
> Which is what should be used for local includes to make sure you
> don't 
> include similar files from other places. That's probably overkill.
> These are the rules it applies:
> - For the quote form of the include directive, the directory of the 
> current file is searched first.
> - For the quote form of the include directive, the directories
> specified 
> by -iquote options are searched in left-to-right order, as they
> appear 
> on the command line.
> - Directories specified with -I options are scanned in left-to-right
> order.
> - Directories specified with -isystem options are scanned in 
> left-to-right order.
> - Standard system directories are scanned.
> - Directories specified with -idirafter options are scanned in 
> left-to-right order.

Yes, I'd seen all of that, thanks though. Essentially it boils down to
the same fundamental concept, with a mechanism available for specifying
some extra quote-only search locations.

>  > On that basis, the existing common use of quotes always fails to
> find
>  > the config.h file, since it exists within the build directory, not
>  > within the <source>/{src|modules|bin|lib|compat} etc
> subdirectories
>  > that those files doing the includes are located within, and thus
> always
>  > falls back to the same search as if we were using angle brackets.
>  > Switching to angle brackets thus only has the difference of
> skipping
>  > the pointless initial same-directory check done when using quotes.
>  >
>  > Thus the only way to unintentionally pick up a config.h from a
> contrib
>  > rather than the vlc one in our build directory would be for the
> contrib
>  > one to appear in a "-I" path, and for that path to be given and
> thus
>  > checked before the build directory, and if this were the case,
> we'd
>  > already be affected by it.
>  >
>  > Am I wrong? I may well be, but if so could someone please explain.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list