[cfe-dev] Include Default C++ paths

Mohammad Adil madil90 at gmail.com
Thu Oct 18 00:22:24 PDT 2012


I've been looking at the source code of the Driver. What I have understood
till now is that the driver is created for the platform we are working on.
The driver  can then build a compilation object from a list of arguments.
Inside this compilation object, there exists a toolchain specific to the
platform (e.g. Linux in my case) which has the job of inserting correct
system and C++ include paths. Is that correct? Let us say that I have build
such a compilation object. How can I create a CompilerInvocation or
CompilerInstance out of this such that it includes the information about
all default C and C++ paths? I see no way of using the driver to just
create an AST and parse it so the only way is to create a Driver and
somehow create a CompilerInstance out of it.

On Thu, Oct 18, 2012 at 1:09 AM, Manuel Klimek <klimek at google.com> wrote:

> On Wed, Oct 17, 2012 at 6:50 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> (readding cfe-dev)
>>
>>
>>
>> On Wed, Oct 17, 2012 at 9:42 AM, Mohammad Adil <madil90 at gmail.com> wrote:
>> > What I am trying to do is to make a small program which parses the AST
>> and
>> > does some rewriting to output modified code. How will I use the Driver
>> in
>> > this case? All I want to do is to parse the AST.
>>
>> I don't know off-hand what the best way to integrate the Driver's
>> lib/header discovery is, just that that's where the logic is.
>>
>> The focus of Clang development with regard to "tools" like the one you
>> described is the Tooling infrastructure (overview of options & a link
>> to libTooling-specific information can be found here:
>> http://clang.llvm.org/docs/Tooling.html ). I'm not sure if that meets
>> the "standalone execution" scenario that you seem to be going for -
>> it's ideally meant to integrate with code already building using an
>> existing build system that has been modified to generate a database of
>> compilation commands. I /think/ it should also work standalone & still
>> do all the driver-based discovery, but I could be wrong.
>>
>
> It does not fully do the driver-based discovery, but it'll usually work
> with the same flags that you provide to a normal clang call - and you can
> always specify options after "--" if you build the tool like in the
> tutorials.
>
> Cheers,
> /Manuel
>
>
>>
>> > On Wed, Oct 17, 2012 at 9:39 PM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>> >>
>> >> On Wed, Oct 17, 2012 at 9:29 AM, madil90 <madil90 at gmail.com> wrote:
>> >> > Hi,
>> >> >    I am trying to parse a C++ code but clang doesn't recognize the
>> C++
>> >> > types. Consider the following code
>> >> >
>> >> > #include <iostream>
>> >> > #include <string>
>> >> >
>> >> > int main()
>> >> > {
>> >> >     string str;
>> >> > }
>> >> >
>> >> > clang gives an error at <iostream> and doesn't recognize the string
>> >> > type. To
>> >> > enable C++, I did "langOptions.CPlusPlus=1" and the code recognizes
>> >> > custom
>> >> > C++ classes. So how do I include default C++ paths?
>> >>
>> >> I assume you're using clang as a library, rather than actually going
>> >> through the clang driver? The driver's where all (most) of the header
>> >> search logic is. You can extract the paths by simply asking clang what
>> >> command it used to invoke the frontend (I forget offhand, but there is
>> >> a verbose/print-commands option to clang) & just pass those in. But if
>> >> you want to make a tool using clang as a library & have the same
>> >> header/lib discovery that the clang command line program has, you'd
>> >> need to duplicate or reuse the logic in the driver.
>> >>
>> >> - David
>> >
>> >
>> >
>> >
>> > --
>> > Mohammad Adil
>> > LUMS SSE
>> >
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>


-- 
Mohammad Adil
LUMS SSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121018/cba03c69/attachment.html>


More information about the cfe-dev mailing list