Re: gobject-introspection on OS X 10.9: clang include <> vs "" fussiness

[Youri Mouton <youri.mout%gmail.com@localhost>]

Make sure WRKOBJDIR isn't in a symlinked place. The error with gobject-introspection happened to me when WRKOBJDIR was in /tmp on OS X, where it is symlinked to /private.

> On 06 Apr 2015, at 14:48, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
> 
> 
> Katarzyna Ciarcińska <kasia%albedo.art.pl@localhost> writes:
> 
>>> I got lots of failures about not finding include files, which sure
>>> enough were included with <> even though they were in the source
>>> directory with the .c files.  I changed most to "" and got this to
>>> build.  In addition I had to change gitestmacros.h to ../gitestmacros.h.
>> 
>> I cannot reproduce this problem on OS X 10.9 with Xcode 6.2
>> (clang-600.0.57). Coulb be something wrong with your local
>> installation?
> 
> So especially given that, there is something wrong.  But I wonder what
> and how to find it.  With my patches, the build of atk then fails with a
> similar issue.
> 
> What I'm not following is whether these programs are setting up -I to
> the source directory, or what their intent is.  The C standard says that
> both the <> and "" search paths are implementation defined.  gcc docs
> imply that <> does not search the source directory (abssent -I).
> Indeed, it does not.  With:
> 
> -------------------- a.c --------------------
> #include <a.h>
> -------------------- a.h --------------------
> #warning a.h
> ----------------------------------------
> 
> the following produce errors
> 
> gcc -c a.c
>  a.c:1:15: fatal error: a.h: No such file or directory
>  compilation terminated.
> 
> clang -c a.c
>  a.c:1:10: error: 'a.h' file not found with <angled> include; use "quotes" instead
>  #include <a.h>
>           ^~~~~
>           "a.h"
>  In file included from a.c:1:
>  ./a.h:1:2: warning: a.h [-W#warnings]
>  #warning a.h
>   ^
>  1 warning and 1 error generated.
> 
> With -I., it works.
> 
> 
> So it seems something is eating an -Isrcdir option that should be
> present.
> 
> Beyond that, it seems these are source files, not system headers, so the
> C files really should be using "".  (Which is not the same as pkgsrc
> should change them.)