[cfe-dev] standalone tool: best way to find built-in includes?

[Christian Convey]

Hi Manuel,

What really matters is that when my tool analyzes the target program's
source, it assumes the same standard headers that are normally used to
build that target program.

For example, the target program might normally be built with clang
3.4, but my analysis tool is built on clang 3.6.  When my tool
analyzes the source code of the target program, I want the analysis to
be as though the target program #include'd the 3.4 builtins, not the
3.6 builtins.  Because my goal is to obtain the same AST as the one
created during the target program's normal (3.4) build process.

If I understand your suggestion, my analysis would give me an AST
based on the clang 3.6 builtins, not based on the 3.4 builtins.  Is
that correct?

Thanks,
Christian





On Fri, Nov 21, 2014 at 4:35 AM, Manuel Klimek <klimek at google.com> wrote:
> +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*.
>
> Thus, optimally you'll install your tool into some/bin and the builtin
> headers into some/lib/clang/<version>.
>
> Cheers,
> /Manuel
>
> On Fri Nov 21 2014 at 5:23:16 AM Sean Silva <chisophugis at gmail.com> wrote:
>>
>> 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)`).
>>
>> 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.
>>
>> -- Sean Silva
>>
>> On Thu, Nov 20, 2014 at 6:32 PM, Christian Convey
>> <christian.convey at gmail.com> wrote:
>>>
>>> Hi guys,
>>>
>>> I'm developed a standalone tool for analyzing source code.  It uses
>>> CommonOptionParser and ClangTool in what I think are the standard
>>> ways.
>>>
>>> My tool analyzes some other code ("foo.c") we have.  We build foo.c
>>> with clang the system-wide installed version of clang.  Thanks to
>>> cmake, we also produce a compilation database for that build of foo.c.
>>>
>>> I'd really like to ensure that when my analysis tool runs, I'd like it
>>> to simulate, as closely as possible, the way we normally build foo.c.
>>> In particular, I'd like to be sure it's using the same builtin headers
>>> and gcc-provided headers.
>>>
>>> Unfortunately, I can't easily copy my analysis tools executable into
>>> the same directory as the clang which we use to build foo.c.
>>>
>>> So here's my question: Is there a good way for me to force my tool to
>>> search the same include directories, in the same order, as our normal
>>> copy of clang does when it's building foo.c?
>>>
>>> I've tried running "clang -### ..." in the build system for foo.c, so
>>> that (I think) I get explicit information about the flags being passed
>>> to the front-end.  However, I haven't found a way to pass those flags
>>> to my analysis tool in a way that CommonOptionsParser and/or ClangTool
>>> find acceptable.  For example, they reject "-cc1".
>>>
>>> Thanks,
>>> Christian
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev