[cfe-dev] Compatibility with MSVC #include "FILE" search order

[Abramo Bagnara]

Il 09/11/2012 11:51, David Röthlisberger ha scritto:
> On 9 Nov 2012, at 09:27, Abramo Bagnara wrote:
>> In http://msdn.microsoft.com/en-us/library/36k2cdd4%28v=vs.100%29.aspx
>> it is written:
>>
>>> Quoted form
>>>
>>> The preprocessor searches for include files in the following order:
>>>
>>> 1. In the same directory as the file that contains the #include
>>> statement.
>>>
>>> 2. In the directories of any previously opened include files in the
>>> reverse order in which they were opened. The search starts from the
>>> directory of the include file that was opened last and continue
>>> through the directory of the include file that was opened first.
>>>
>>> 3. Along the path specified by each /I compiler option.
>>>
>>> 4. Along the paths specified by the INCLUDE environment variable.
>>
>> In clang do we have an option to emulate the point 2?
> 
> 
> Abramo, I don't know the answer to your question so I apologise for the
> unhelpful reply, but I was a bit confused by what difference this would
> make, so I'm posting in case it saves anyone else some time puzzling it
> out.
> 
> Note that the Visual Studio 2005 documentation[1] is clearer as to
> exactly which paths are searched: "[The double-quoted #include form
> searches in] the same directory of the file that contains the #include
> statement, and then in the directories of any files that include
> (#include) that file".
> 
> [1] http://msdn.microsoft.com/en-us/library/36k2cdd4(v=vs.80).aspx
> 
> How are previously-opened include files found, if not by rules 1, 3 & 4?
> So I guess that #2 is only to affect the *order* the paths are searched
> in, rather than to add new paths that would otherwise not be searched.
> Is that correct?
> 
> It seems to me that the only scenario where rule #2 has any effect is
> when there are two header files with the same name, in different
> directories, but not in the directory of the file #includeing it:
> 
>     A/a.c: #include "b.h"
>     B/b.h: #include "c.h"
>     C/c.h: #include "where.h"
> 
> With the search path -IA -IB -IC: If there are two files A/where.h and
> B/where.h, rule #2 would find B/where.h. The cpp on my system (OS X
> Lion) finds A/where.h.
> 
> C99 (§6.10.2) says "The named source file is searched for in an
> implementation-defined manner". How annoying. :-)
> 
> Note that if where.h exists in C/, then both implementations pick
> C/where.h.

Hi David,

this is an example:

$ cat p.c
#include "p.h"
$ cat q/p.h
#include "p1.h"
$ cat p1.h
$ gcc -E -I q p.c
# 1 "p.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "p.c"
# 1 "q/p.h" 1
In file included from p.c:1:0:
q/p.h:1:16: fatal error: p1.h: No such file or directory
compilation terminated.

If you compile it with cl.exe you get no errors, the difference is in
point #2 (i.e. p1.h is searched also in the directory of p.c)

-- 
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagnara at bugseng.com