[cfe-users] Building clang with "relative incldue paths"

[Matthias Maier]

Am 13. Feb 2014, 13:52 schrieb Kevin Ingwersen <ingwie2000 at googlemail.com>:

> Hello there.
>
> I would like to embed clang into one of my projects, a more automated
> build system. Since I prefer Clang over GCC, I would like to use
> it. But for that to work properly, I would need to change the order of
> folders that are searched for libs and includes by default, so it
> would look similar to:
>
> 	- /path/to/clang/../includes
> 	- /usr/include
> 	- …
>
> That is, because the tool comes with some pre-compiled libraries and
> their headers - so i want those to be seen before the system ones.

I do not understand. Every path you specify by either -I or -L takes
precedence over system paths. Can you give a precise example on what is
going wrong?

Please also note that the clang driver mimics the gcc frontend very
closely, so I'm surprised that there could be a noticable difference.

You can examine in detail by invoking clang with the "-v" switch,
e.g. on my system it reads:

 $ clang -v -I/tmp/project/include -c test.c

    #include "..." search starts here:
    #include <...> search starts here:
     /tmp/project/include
     /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4
     /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/x86_64-pc-linux-gnu
     /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/backward
     /usr/bin/../lib/clang/3.4/include
     /usr/include

> What config option can I pass to have that work? I see that clang does
> that in the apple toolchain, and no matter where I place it, the path
> to the binary is always correct. So I guess its able to resolve the
> full path to itself, and then append the relative path to the
> includes, or libs.

Currently, the low level toolchain include paths are more or less
compiled statically into the executable, so there is (almost) no way to
either alter or mimic it.

Best,
Matthias