Attached is an updated patch.
Anton,
I think the bulleted list might benefit from restructuring a bit to
make it sound more like a recommendation on what needs to be done
under different circumstances.
Restructured the bulleted list, now it looks much more better.
My understanding is that the most reliable way is to use MinGW instead
of make. (This is addressed by the first bullet.)
However, some projects might get away with using make. In that case,
the other recommendations (2d and 3d bullet) would apply.
There are two reliable ways - either use pure MinGW or run make from the
sh shell. The 2d bullet is really a recipe for healing a problem from
the 1st bullet, eliminated it.
Pleas look at the updated list.
Thank you for looking at this!
Is this correct?
Thanks,
Anna.
On Oct 20, 2014, at 1:49 PM, Anton Yartsev <[email protected]
<mailto:[email protected]>> wrote:
Updated the "For Windows Users" section with helpful hints, OK to commit?
Anton,
Thanks for the investigation.
Please, send the proposed wording as a patch. (Not sure if it would
be possible to describe the symptoms of the problem.)
Anna.
On Oct 18, 2014, at 1:56 AM, Anton Yartsev <[email protected]
<mailto:[email protected]>> wrote:
As I was explained in the MSYS community the MSYS utils are
dependent on the MSYS runtime and their usage from cmd.exe is
unsupported. "You are welcome to try it, but if you observe odd
behaviour, such as here, then you are out of luck".
I performed several tests and found out that proper processing is
performed with either running scan-build with MSYS make in the
following way:
scan-build ... sh -c "make"
or with using mingw32-make and removal of MSYS from PATH (otherwise
mingw32-make tries to use MSYS utils).
from the MinGW FAQ:
"What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in
some functionality and has modified functionality due to the lack
of POSIX on Win32. There also exists a version of make in the MSYS
distribution that is dependent on the MSYS runtime. This port
operates more as make was intended to operate and gives less
headaches during execution. Based on this, the MinGW
developers/maintainers/packagers decided it would be best to rename
the native version so that both the "native" version and the MSYS
version could be present at the same time without file name collision."
Is it OK to add the recommendations to thescan-build: running the
analyzer from the command line
<http://clang-analyzer.llvm.org/scan-build.html#scanbuild_forwindowsusers>,
"For Windows Users" section?
Sorry, that's not a solution.
The goal of the patch is to pass unmodified arguments to
compilers as they were written in the makefile. Arguments taken
from @ARGV may be modified by the system and Perl, at least
quotes and backslash sequences are processed. Using this
arguments may cause compiler errors. Sometimes system+Perl
corrupt arguments completely, for example, using perl from MSYS
1.0 on Windows I got:
Line from makefile:
$(CXX) -DMACRO=\"string\" file.cpp "asd dff ghh" -o file.exe
arguments red from @ARGV by c++-analyzer:
"-DMACRO=\string\" file.cpp -o file.exe"
Please review!
--
Anton
--
Anton
<scan-build.html.patch>
--
Anton
Index: scan-build.html
===================================================================
--- scan-build.html (revision 220907)
+++ scan-build.html (working copy)
@@ -124,12 +124,40 @@
<h3 id="scanbuild_forwindowsusers">For Windows Users</h3>
-<p>Windows users must have Perl installed to use scan-build. Currently scan-build
-is known to work with the msys perl port.</p>
+<p>Windows users must have Perl installed to use scan-build.</p>
-<p>scan-build.bat script allows you to launch scan-build in the same way as it described in the Basic Usage section above.
-All you need to be able to invoke scan-build from an arbitrary location is to add the path to scan-build to your PATH environment variable.</p>
+<p><tt>scan-build.bat</tt> script allows you to launch scan-build in the same
+way as it described in the Basic Usage section above. All you need to be able
+to invoke scan-build from an arbitrary location is to add the path to scan-build
+to your PATH environment variable.</p>
+<p>If you have unexpected compilation/make problems when running scan-build
+with MinGW/MSYS the following information may be helpful:</p>
+
+<ul>
+ <li> <b>Symptoms:</b> unexpected <i>"fatal error: no input files."</i> compiler
+error while building with MSYS <tt>make</tt> from the Windows cmd.<br>
+<b>Recipe1:</b> Try using MinGW <tt>mingw32-make</tt> instead of MSYS
+<tt>make</tt>, exclude path to MSYS from PATH to prevent <tt>mingw32-make</tt>
+from using MSYS utils.<br>
+<b>Recipe2:</b> Run <tt>make</tt> from the sh shell (<i>scan-build
+[options] sh -c "make [options]"</i>) rather then from the Windows cmd
+(<i>'scan-build [options] make [options]</i>).<br>
+<b>Note:</b> MSYS utils are dependent on the MSYS runtime and they are not
+intended for being run from the Windows cmd. Specifically, makefile commands
+with backslashed quotes may be heavily corrupted when passed for execution.
+<br>See <a href="http://www.mingw.org/wiki/FAQ";>MinGW FAQ</a>,
+<i>"What's the difference between make and mingw32-make?"</i> section for
+additional information about <tt>make</tt> and <tt>mingw32-make</tt>.
+<li> <b>Symptoms:</b> <i>"Error : *** target pattern contains no `%'."</i>
+try to use another version of <tt>make</tt>.<br>
+<b>Recipe:</b> Check you version of <tt>make</tt>. If it is <i>GNU Make 3.81</i>
+then try using another version.<br>
+<b>Note:</b> <i>GNU Make 3.81</i> has a known
+<a href="http://www.cmake.org/pipermail/cmake/2008-May/022029.html";>bug</a>
+related to incorrect handling of Windows paths.
+</ul>
+
<h3 id="scanbuild_otheroptions">Other Options</h3>
<p>As mentioned above, extra options can be passed to <tt>scan-build</tt>. These
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
