[cfe-dev] Default Headers with CompilerInstance

[Manuel Klimek]

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

> Thank you for you answers:
>
> @ Jordan
> > Is -internal-isystem the flag that controls this? That seems to be what
> lit is using for %clang_cc1.
> Thank you. I looked up into Clang's sources and found many relevant
> references to this option, right into the Driver.
>
> @ Manuel
> > 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).
> That is right. The implementations of the Driver (and ToolChain) seem to
> feature some nice features I should use.
>
> I guess that means I will have forget about any CompilerInstance object.
> Do you have any code snippet that uses the Driver ?
> And by the way, will I still be able to use ASTParser() ?
>

See:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Tooling.cpp?revision=166508&view=markup
The implementation of the Tooling library uses the drive exactly in the way
you'd need to use it - you can either copy that code, or use the Tooling
library :)

Cheers,
/Manuel


>
> Regards
>
> - Antoine
>
> Le H.24/11/13 à 11:11, Manuel Klimek <klimek at google.com> a écrit :
>
> > 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/4f6f7a1e/attachment.html>