Hi Jon,<div><br></div><div>Thanks for the patch! </div><div><br></div><div>My feeling is we should fix this bug in clang-cc, not the driver, though. I would also argue for making an makeAbsolute method on llvm::sys::Path.</div>
<div><br></div><div>This is PR3464 by the way:</div><div><a href="http://llvm.org/bugs/show_bug.cgi?id=3464">http://llvm.org/bugs/show_bug.cgi?id=3464</a></div><div><br></div><div>I think the cleanest way to handle this would be to allow the predefines buffer to supply the current directory as the place to start the header search, so the usual search mechanisms handle the resolution. I'm not sure what this involves, however.</div>
<div><br></div><div> - Daniel<br><br><div class="gmail_quote">2009/4/5 Jon Simons <span dir="ltr"><<a href="mailto:simonsj@ccs.neu.edu">simonsj@ccs.neu.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Attached is a patch to fix '-include' for clang (PR 3395).<br>
<br>
Currently, paths fed to '-include' are treated as relative to the<br>
compliation unit at hand, instead of to the current working directory<br>
from which clang was invoked.  The patch coerces relative paths into<br>
absolute ones, which seem to be handled just fine by the Lexer and<br>
Preprocessor.<br>
<br>
That said, this feels a bit hackish.  I hate munging paths.  It's<br>
entirely possible someone more familiar could suggest a cleaner way<br>
:).  Nothing is jumping out at me from my cursory, hobbyist readings.<br>
<br>
<br>
Cool Beans,<br><font color="#888888">
-Jon Simons<br>
</font><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>