[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:
> -DHAVE_CONFIG_H
> -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