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

[Kevin Ingwersen]

Hey.

Thanks for your fast response!

Yep, I know about the -v option to look at what Clang is doing, and that is exactly where I saw something thet interested me - i’ll highlight what i mean.

Ingwie at Ingwies-Air /tmp $ nano test.c
Ingwie at Ingwies-Air /tmp $ cat test.c
int main() { return 0; }
Ingwie at Ingwies-Air /tmp $ clang -v test.c
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
 "/Applications/drag0n/drag0n.app/Contents/System/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 224.1 -v -resource-dir /Applications/drag0n/drag0n.app/Contents/System/usr/bin/../lib/clang/5.0 -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 272 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/sd/6zp4rxhs61xcp5ymdd5_fgq80000gn/T/test-dKNjJ0.o -x c test.c
clang -cc1 version 5.0 based upon LLVM 3.3svn default target x86_64-apple-darwin13.0.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Applications/drag0n/drag0n.app/Contents/System/usr/bin/../lib/clang/5.0/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/Applications/drag0n/drag0n.app/Contents/System/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o a.out /var/folders/sd/6zp4rxhs61xcp5ymdd5_fgq80000gn/T/test-dKNjJ0.o -lSystem /Applications/drag0n/drag0n.app/Contents/System/usr/bin/../lib/clang/5.0/lib/darwin/libclang_rt.osx.a
Am Do. Feb. 13 2014 14:32:45 schrieb Matthias Maier:

Yep, I „stole“ the apple toolchain to another folder, because I was making an experiment with it. And at that point, I noticed that it was looking into a relative path as well as absolute paths.

My question was, how can I add my own relative path to the list?
Is it some configure/Cmake option that I can pass?

Kind regards,
Ingwie.

> 
> 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
> _______________________________________________
> cfe-users mailing list
> cfe-users at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20140213/9893fbda/attachment.html>