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.)
Attachment:
pgpJdBQe1D1wb.pgp
Description: PGP signature