[cfe-dev] Default Headers with CompilerInstance

[Manuel Klimek]

On Mon, Nov 12, 2012 at 5:19 PM, Antoine Trouve <trouve at isit.or.jp> wrote:

> Thank you for all your answers and sorry for the late reaction.
>
> Let we avoid any misunderstanding. I can compile Clang and I can compile
> my tool without any issue.
> The issue with systems headers occurs when I execute my tool, and when my
> tool parses a C file (or preprocesses it, with a "Preprocessor" object).
>
> If I sum up your answers, there is no "magic" way that would make Clang
> API know about the path of my system headers.


That is true.


> I have to "hard-code" them.
>

That is not true :) While not "magic", the way to do this is to use the
Driver (which is exactly what clang-the-compiler uses to find the system
and builtin includes).


>
> I find that a bit weird as when I compile Clang from the svn and use it as
> a frontend for LLVM to compile my files, it finds the headers without any
> intervention from myself.
> Moreover, I've noticed that if I use libclang as defined in "Index.h" it
> also finds these. In this case however, I have to pass an argument to the
> function "clang_createTranslationUnitFromSourceFile" (at least "-Xclang",
> even without any further parameters is OK). However I've quitted with using
> it as seems no to feature any routines to parse the AST node by node,
> modify it and deserialize it.
>
> I haven't tried the tooling library yet, does it feature such
> possibilities ?
>

Yes. It uses the driver and a compilation database so it gets the exact
same flags your normal compile gets, which, combined, will lead to the
right headers being found in the right places.

Cheers,
/Manuel


>
> Best regards,
>
> - Antoine
>
> Le H.24/11/09 à 4:21, Manuel Klimek <klimek at google.com> a écrit :
>
> > On Thu, Nov 8, 2012 at 10:42 AM, Mehdi AMINI <mehdi.amini at silkan.com>
> wrote:
> > Hi,
> >
> >
> >
> > Le 08/11/2012 10:22, Manuel Klimek a écrit :
> >
> > See here for what's needed to build a tool on top of clang:
> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Tooling.cpp?revision=166508&view=markup
> > (the solution is to use the Driver, which handles finding of builtin and
> > system includes)
> >
> > Alternatively, you can just use the tooling library :) (see
> > http://clang.llvm.org/docs/LibTooling.html)
> >
> > None of these solutions relieves you from building your binary at the
> same place at Clang is installed, or duplicate the Clang headers along your
> tool installation so that they are in PATH_TO_BIN/../lib/...
> > Or did I miss something at some point?
> >
> > What you can do is slurp up the builtin headers as char*'s in your
> sources, compile them into your binary, and use virtual files at runtime
> with LibTooling (we're actually doing that for our internal mapreduce
> framework).
> >
> > The problem with this approach, and the main reason Chandler has opposed
> doing that for quite some time, is that when you see errors that reference
> the builtin headers you'll not be able to open those files from your editor
> (Chandler will jump in if I misrepresented his views :)
> >
> > Cheers,
> > /Manuel
> >
> >
> >
> >     I tried to add the system headers manually using
> >     "HeaderSearchOptions.Add" but (1) this is not portable and (2)
> >     anyway I can't make that work either.
> >
> >     Could you please explain me more in details how Clang does to find
> >     the default system headers ?
> >     I attach the source file of my simple prototype.
> >
> >
> > From my (very shallow) experience, unless you get very deep with the
> initialization it end up by looking the headers from the place the binary
> is installed.
> >
> > Best,
> >
> > Mehdi
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121112/90ac8c34/attachment.html>