[cfe-dev] Include Default C++ paths

[Sean Silva]

Another problem that you are likely to run into is that there are some
headers like stddef.h which are looked for in a hardcoded path
relative to the binary itself, so you must either hardcode the path on
your system in some way, or run your tool only in particular
directories.

The problem that you are having is probably the #1 most annoying thing
for me about clang. When I was getting started with clang I spent more
time than I wish to admit on exactly what you are trying to do now,
and basically my conclusion was that Clang does not support this use
case currently (i.e., using clang as a library to simply parse an
arbitrary C++ file and then do stuff with the AST or whatever).
libTooling was not around back then, so libTooling might be a way to
accomplish what you want. You are going to waste a lot of time if you
try to manually do this though---I certainly did.

Someday, we may be able to say ParseFile("foo.cpp") which just gives
you the ASTContext for the parsed file, but we currently do not, and
it is a *really*, **really** hard problem to be able to make something
like that "just work".

A plugin is a way to get around this though, but your tool may or may
not fit into the plugin model. If all you want though is to get the
ASTContext and do something with it, then a plugin is the way to go
currently.

-- Sean Silva

On Thu, Oct 18, 2012 at 3:22 AM, Mohammad Adil <madil90 at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>