+1 to needs some refactoring, but generally the trick is: you don't want to use the builtin includes that are used by the clang you used to produce the compilation database, but the one that is current at the version at which you built your *tool*.<div><br><div>Thus, optimally you'll install your tool into some/bin and the builtin headers into some/lib/clang/<version>.</div></div><div><br></div><div>Cheers,</div><div>/Manuel</div><br><div class="gmail_quote">On Fri Nov 21 2014 at 5:23:16 AM Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You can set CLANG_RESOURCE_DIR in CMake, or pass -resource-dir (the default resource dir is created by `llvm::sys::path::append(<exe-path>, "..", "lib", "clang", CLANG_VERSION_STRING)`).<div><br></div><div>This logic is actually duplicated in more than one place unfortunately. e.g. in CompilerInvocation::GetResourcesPath (lib/Frontend/CompilerInvocation.cpp) and Driver::Driver (lib/Driver/Driver.cpp); there's also some nastiness in CIndexer::getClangResourcesPath. Needs some refactoring.</div></div><div dir="ltr"><div><br></div><div>-- Sean Silva</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 20, 2014 at 6:32 PM, Christian Convey <span dir="ltr"><<a href="mailto:christian.convey@gmail.com" target="_blank">christian.convey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
I'm developed a standalone tool for analyzing source code.  It uses<br>
CommonOptionParser and ClangTool in what I think are the standard<br>
ways.<br>
<br>
My tool analyzes some other code ("foo.c") we have.  We build foo.c<br>
with clang the system-wide installed version of clang.  Thanks to<br>
cmake, we also produce a compilation database for that build of foo.c.<br>
<br>
I'd really like to ensure that when my analysis tool runs, I'd like it<br>
to simulate, as closely as possible, the way we normally build foo.c.<br>
In particular, I'd like to be sure it's using the same builtin headers<br>
and gcc-provided headers.<br>
<br>
Unfortunately, I can't easily copy my analysis tools executable into<br>
the same directory as the clang which we use to build foo.c.<br>
<br>
So here's my question: Is there a good way for me to force my tool to<br>
search the same include directories, in the same order, as our normal<br>
copy of clang does when it's building foo.c?<br>
<br>
I've tried running "clang -### ..." in the build system for foo.c, so<br>
that (I think) I get explicit information about the flags being passed<br>
to the front-end.  However, I haven't found a way to pass those flags<br>
to my analysis tool in a way that CommonOptionsParser and/or ClangTool<br>
find acceptable.  For example, they reject "-cc1".<br>
<br>
Thanks,<br>
Christian<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div>