[cfe-dev] Clang tooling and absolute filenames

[Jonathan Anderson]

On Friday, 19 April 2013 at 12:53, Manuel Klimek wrote:

> That would be me :)

Nice to meet you. :)
  

> What breaks due to that disagreement?

I have a string constant in foo.ll that is generated from __FILE__ ("foo.c"). This string constant is used during instrumentation to look up information in my analysis results file, which contains information from all translation units. The trouble is, the analysis doesn't know about "foo.c", even though I ran it with "analyse foo.c"; it thinks the file is called "/Users/jon/[…]/foo.c".

I currently get around this by running my analysis results through sed to remove the "/Users/jon/[…]/" part, but that's pretty hacky (and it won't work if I switch my protobuf output from text representation to binary). Another approach would be to modify my makefile to pass absolute filenames to Clang (in which case its __FILE__ would match what's in the analysis file), but I might like to distribute the analysis file along with the source files it describes, in which case I really, really don't want to be stuck with absolute filenames.

> 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.
Sure, it's the same issue that I have, but the relative-absolute problem goes the other way. The problem with the current approach is that the desire to use absolute filenames in one case *precludes* the ability to use relative filenames in the other case. If Clang's Tooling framework defaulted to using "whatever string is passed on the command line" as the filename, however, projects that require absolute filenames could use them but other projects (like mine) that prefer relative names can use those.


Jon
--  
Jonathan Anderson

Research Associate
Computer Laboratory
University of Cambridge

jonathan.anderson at cl.cam.ac.uk
+44 1223 763 747