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

[Steve Lhomme]

On 2020-10-06 20:29, Lyndon Brown wrote:
> 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.

Not just that, I think it clarifies one fundamental difference between 
"" and <>. "" is for files local to your project (current dir or project 
dir) whereas <> is for external files.

MSVC has similar concepts
https://docs.microsoft.com/en-us/cpp/preprocessor/hash-include-directive-c-cpp?view=vs-2019

Here "" includes also look in upper directories before looking in -I 
directories.

There are 3 main categories of include dirs: the project ones, the 
external ones and the system ones. What you are proposing is to consider 
there's just one type and we will manage the order ourselves. It's 
technically what we are doing today but I don't think it's the proper 
way, nor a desirable direction.

This also allows reusing standard header names in local projects without 
wondering if it will be used or the system ones.

>>   > 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
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
>