<div dir="ltr">Thanks. But to address Florent's concern, are there tests that cover the windows command line limit?<div>I guess to test if this breaks we'd need a source file whose compile command is under the limit if using relative path,</div><div>but over the limit if using absolute path.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 8, 2016 at 11:04 AM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/08/2016 01:42 PM, Chaoren Lin wrote:<br>
>> I don't think this hunk is needed anymore, correct?<br>
><br>
> That hunk is the opposite now<br>
<br>
</span>Oops, right.  That actually fixes the existing RC bug I mentioned<br>
earlier in this thread.<br>
<br>
With your patch the use of IN_ABS breaks builds with spaces in the<br>
path.  The reason is that Ninja handles quoting of paths when<br>
replacing  the `$in` placeholder but does nothing special for<br>
`$IN_ABS`.  CMake will have to generate the right path in the value.<br>
<br>
I've applied the patch with the appropriate modification for that:<br>
<span class=""><br>
 Ninja: Use full path for all source files<br>
</span> <a href="https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=955c2a63" rel="noreferrer" target="_blank">https://cmake.org/gitweb?p=<wbr>cmake.git;a=commitdiff;h=<wbr>955c2a63</a><br>
<br>
Thanks,<br>
-Brad<br>
<br>
</blockquote></div><br></div>