[cfe-dev] Clang tooling and absolute filenames

[Manuel Klimek]

On Thu, Apr 18, 2013 at 6:15 PM, Jonathan Anderson <
jonathan.anderson at cl.cam.ac.uk> wrote:

> Hi,
>
> I've written a Clang tool that does some analysis of a C program and uses
> the results to guide instrumentation of the resulting LLVM IR. This tool
> (and the attendant research) wouldn't have happened without Clang, so
> thanks to all you maintainers! I have encountered one problem, however,
> which is trivial to fix but seems to be deeply embedded in someone's
> philosophy of The Way Things Should Be Done.
>

That would be me :)

My issue is that Clang and libClangTooling disagree about the name of the C
> file they operate on: Clang is (quite sensibly) happy to compile "foo.c",
> but when I run my Clang tool, it is converted to
> "/Users/jon/Documents/.../myproject/foo.c" (on line 242 of
> lib/Tooling/Tooling.cpp). Since Clang (the binary) disagrees with Clang
> (the library), I have to resort to a sed script that strips `pwd` out of my
> Clang tool's output!
>

What breaks due to that disagreement?


> I can easily modify Tooling.cpp to use the filename passed to
> libClangTooling, and I would've submitted a patch with this e-mail, but
> there are tests and document that assume compile_commands.json will always
> contain absolute filenames. This seems wrong to me: shouldn't the canonical
> name of a file be whatever was passed to the compiler at the command line?
> Since tools like clang-check already provide arguments that separate the
> working directory from filenames, why do we have to refer to absolute
> filenames in compile_commands.json?
>

The problem with relative paths is when you get a path handed in, and
you're trying to figure out which command line applies to it.

Cheers,
/Manuel


>
>
> Jon
> --
> Jonathan Anderson
>
> Research Associate
> Computer Laboratory
> University of Cambridge
>
> jonathan.anderson at cl.cam.ac.uk
> +44 1223 763 747
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130419/d96656a7/attachment.html>