<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 27.04.2013 6:49, Jordan Rose wrote:<br>
</div>
<blockquote
cite="mid:A0966300-4493-43A1-81C9-62D5635FB695@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Apr 26, 2013, at 19:46 , Anton Yartsev <<a
moz-do-not-send="true" href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 27.04.2013 5:07, Jordan Rose
wrote:<br>
</div>
<blockquote
cite="mid:C10FA7B4-EB5F-4433-B93C-29C4E5B4F527@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><br>
</div>
<div>
<div>On Apr 26, 2013, at 11:26 , Anton Yartsev <<a
moz-do-not-send="true"
href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On 22.04.2013 23:51, Jordan Rose
wrote:<br>
<blockquote type="cite"> Better MinGW support is
certainly welcome! A few comments, though...<br>
<br>
<br>
================<br>
Comment at: tools/scan-build/scan-build:1563<br>
@@ -1562,3 +1562,3 @@<br>
$ClangCXX = $Clang;<br>
-$ClangCXX =~ s/\-\d+\.\d+$//;<br>
-$ClangCXX .= "++";<br>
+if($^O =~/msys/) {<br>
+ $ClangCXX =~ s/.exe$/++.exe/;<br>
----------------<br>
Not being a native Perl hacker, I found this a bit
confusing. `$OSNAME` would have been a bit
friendlier.<br>
<br>
Also, this check //only// handles MinGW, correct? <a
moz-do-not-send="true"
href="http://perldoc.perl.org/perlvar.html#General-Variables">http://perldoc.perl.org/perlvar.html#General-Variables</a>
says that native Windows returns "MSWin32" here.<br>
<br>
================<br>
Comment at: tools/scan-build/c++-analyzer.win:3<br>
@@ +2,2 @@<br>
+<br>
+system ("ccc-analyzer @ARGV");<br>
----------------<br>
The reason we have c++-analyzer at all is so that we
can set run the underlying compilation with a C++
compiler. Simply forwarding c++-analyzer.win to
ccc-analyzer won't actually accomplish that --
you'll have to add a flag or enviroment variable
check to ccc-analyzer, which c++-analyzer.win can
set before invoking ccc-analyzer.<br>
<br>
Also, are you sure this won't destroy arguments with
spaces in them? (You can test with something like
`"-DSTR=macro with spaces"`.)<br>
<br>
<br>
<a moz-do-not-send="true"
href="http://llvm-reviews.chandlerc.com/D703">http://llvm-reviews.chandlerc.com/D703</a><br>
</blockquote>
Thanx for the review, all of your fears were
confirmed.<br>
Attached is a new patch.<br>
<br>
Temporary excluded phabricator from recipients.<br>
</blockquote>
</div>
<br>
<div>This doesn't actually fix either problem nicely. ;-)
The advantage of a symlink over a wrapper script is that
the indirection cost is <i>tiny...</i>at least on
platforms where that trick works. That said, it does
seem silly to have both a c++-analyzer symlink and a
c++-analyzer.win wrapper script. How about moving the
bulk of ccc-analyzer into a separate .pm file, which you
can then load from ccc-analyzer and c++-analyzer? That
solves the quoting problem, too.</div>
</blockquote>
Great idea! I'll try to implement it this way.<br>
</div>
</blockquote>
</div>
</blockquote>
Done!<br>
New patch attached.<br>
<br>
<pre class="moz-signature" cols="72">--
Anton</pre>
</body>
</html>