<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hey.<div><br></div><div>Thanks for your fast response!</div><div><br></div><div>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.</div><div><br></div><div>Ingwie@Ingwies-Air /tmp $ nano test.c<br>Ingwie@Ingwies-Air /tmp $ cat test.c<br>int main() { return 0; }<br>Ingwie@Ingwies-Air /tmp $ clang -v test.c<br>Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)<br>Target: x86_64-apple-darwin13.0.0<br>Thread model: posix<br> "/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<br>clang -cc1 version 5.0 based upon LLVM 3.3svn default target x86_64-apple-darwin13.0.0<br>#include "..." search starts here:<br>#include <...> search starts here:<br> /usr/local/include<br><b><u> /Applications/drag0n/drag0n.app/Contents/System/usr/bin/../lib/clang/5.0/include<br></u></b> /usr/include<br> /System/Library/Frameworks (framework directory)<br> /Library/Frameworks (framework directory)<br>End of search list.<br> "/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<br><span>Am Do. Feb. 13 2014 14:32:45 schrieb Matthias Maier:</span><br><br>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.</div><div><br></div><div>My question was, how can I add my own relative path to the list?</div><div>Is it some configure/Cmake option that I can pass?</div><div><br></div><div>Kind regards,</div><div>Ingwie.</div><div><br><blockquote type="cite"><br>Am 13. Feb 2014, 13:52 schrieb Kevin Ingwersen <<a href="mailto:ingwie2000@googlemail.com">ingwie2000@googlemail.com</a>>:<br><br><blockquote type="cite">Hello there.<br><br>I would like to embed clang into one of my projects, a more automated<br>build system. Since I prefer Clang over GCC, I would like to use<br>it. But for that to work properly, I would need to change the order of<br>folders that are searched for libs and includes by default, so it<br>would look similar to:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>- /path/to/clang/../includes<br><span class="Apple-tab-span" style="white-space:pre"> </span>- /usr/include<br><span class="Apple-tab-span" style="white-space:pre"> </span>- …<br><br>That is, because the tool comes with some pre-compiled libraries and<br>their headers - so i want those to be seen before the system ones.<br></blockquote><br>I do not understand. Every path you specify by either -I or -L takes<br>precedence over system paths. Can you give a precise example on what is<br>going wrong?<br><br>Please also note that the clang driver mimics the gcc frontend very<br>closely, so I'm surprised that there could be a noticable difference.<br><br>You can examine in detail by invoking clang with the "-v" switch,<br>e.g. on my system it reads:<br><br>$ clang -v -I/tmp/project/include -c test.c<br><br> #include "..." search starts here:<br> #include <...> search starts here:<br> /tmp/project/include<br> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4<br> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/x86_64-pc-linux-gnu<br> /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/backward<br> /usr/bin/../lib/clang/3.4/include<br> /usr/include<br><br><blockquote type="cite">What config option can I pass to have that work? I see that clang does<br>that in the apple toolchain, and no matter where I place it, the path<br>to the binary is always correct. So I guess its able to resolve the<br>full path to itself, and then append the relative path to the<br>includes, or libs.<br></blockquote><br>Currently, the low level toolchain include paths are more or less<br>compiled statically into the executable, so there is (almost) no way to<br>either alter or mimic it.<br><br>Best,<br>Matthias<br>_______________________________________________<br>cfe-users mailing list<br><a href="mailto:cfe-users@cs.uiuc.edu">cfe-users@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users<br></blockquote><br><div><br></div></div></body></html>