<div dir="ltr">On Fri, Apr 19, 2013 at 3:24 PM, Jonathan Anderson <span dir="ltr"><<a href="mailto:jonathan.anderson@cl.cam.ac.uk" target="_blank">jonathan.anderson@cl.cam.ac.uk</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Friday, 19 April 2013 at 12:53, Manuel Klimek wrote:<br>
<br>
> That would be me :)<br>
<br>
</div>Nice to meet you. :)<br>
<div class="im"><br>
<br>
> What breaks due to that disagreement?<br>
<br>
</div>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".<br>

<br>
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.<br>
</blockquote><div><br></div><div style>I still don't understand how the compilation and the analysis are related, *but*...</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> 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.<br>
</div>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.<br>
</blockquote><div><br></div><div style>Perhaps I don't need to - as far as I understand what you want to change is basically the filename that gets passed to clang as the "main source file name". That sounds like it makes sense. If you whip up a patch and send it to me (preferred on <a href="http://llvm-reviews.chandlerc.com">llvm-reviews.chandlerc.com</a>) I think that makes sense...</div>
<div style><br></div><div style>Or correct me if I seem to have misunderstood your goal...</div><div style><br></div><div style>Cheers,</div><div style>/Manuel</div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5"><br>
<br>
Jon<br>
--<br>
Jonathan Anderson<br>
<br>
Research Associate<br>
Computer Laboratory<br>
University of Cambridge<br>
<br>
<a href="mailto:jonathan.anderson@cl.cam.ac.uk">jonathan.anderson@cl.cam.ac.uk</a><br>
<a href="tel:%2B44%201223%20763%20747" value="+441223763747">+44 1223 763 747</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>