[PATCH][analyzer] Pass original command line arguments to compilers.

Anna Zaks ganna at apple.com
Thu Oct 30 09:41:21 PDT 2014


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.

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.

Is this correct?

Thanks,
Anna.

> On Oct 20, 2014, at 1:49 PM, Anton Yartsev <anton.yartsev at gmail.com> 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 <anton.yartsev at gmail.com <mailto:anton.yartsev at gmail.com>> 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 the scan-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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141030/cfed1814/attachment.html>


More information about the cfe-commits mailing list