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

[Christian Convey]

I had been hoping to avoid that as a requirement, but it sounds like I
can't.  Thanks very much for the help.

- Christian

On Fri, Nov 21, 2014 at 11:24 AM, Manuel Klimek <klimek at google.com> wrote:
> Then I would suggest you compile the code with the same compiler you build
> your tool based on...
>
>
> On Fri Nov 21 2014 at 5:14:39 PM Christian Convey
> <christian.convey at gmail.com> wrote:
>>
>> > The question is, why is it important to you whether it's the same AST?
>>
>> I'm also generating program traces, which report source locations
>> based on the DWARF info.  I want to be able to reliably relate the
>> trace events to the AST.  I want to minimize the risk that the two
>> don't properly match.
>>
>> On Fri, Nov 21, 2014 at 11:00 AM, Manuel Klimek <klimek at google.com> wrote:
>> > On Fri Nov 21 2014 at 4:40:44 PM Christian Convey
>> > <christian.convey at gmail.com> wrote:
>> >>
>> >> 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.
>> >
>> >
>> > The builtin headers are implementation details of the compiler. If you
>> > compile a file with a tool based on clang 3.6 and builtin headers of
>> > clang
>> > 3.4 the probability that you *don't* get a correct AST is higher.
>> >
>> > If you want to get the same AST, you have to use the same version of
>> > clang.
>> > The question is, why is it important to you whether it's the same AST?
>> >
>> >>
>> >>
>> >> 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