[CMake] mingw vs MSYS makefiles

Bill Hoffman bill.hoffman at kitware.com
Thu Feb 23 14:46:00 EST 2012


On 2/23/2012 2:12 PM, Kenneth Boyd wrote:
> On 2/23/2012 5:20 AM, Andrea Crotti wrote:
>> I have MinGW installed in my system and today I added the bin
>> directory to the path, so I was able to
>> run all the commands also from a standard shell.
>>
>> But now CMake complains:
>>
>> CMake Error at c:/Program Files/CMake
>> 2.8/share/cmake-2.8/Modules/CMakeMinGWFindMake.cmake:20 (MESSAGE):
>> sh.exe was found in your PATH, here:
>>
>> C:/MinGW/msys/1.0/bin/sh.exe
>>
>> For MinGW make to work correctly sh.exe must NOT be in your path.
>>
>> Run cmake from a shell that does not have sh.exe in your PATH.
>>
>> If you want to use a UNIX shell, then use MSYS Makefiles.
>>
>>
>> So well I thought I could just use the MSYS Makefiles instead, but
>> reconfiguring and with the same target that doesn't work:
>>
>> Scanning dependencies of target cleanup_system
>> process_begin: CreateProcess(NULL, /c/python25/python.exe
>> h:/git_projs/PSI_Hamburg/utils/utils/bin/clean_global.py, ...) failed.
>> make (e=2): The system cannot find the file specified.
>> epd-make[3]: *** [CMakeFiles/cleanup_system] Error 2
>> epd-make[2]: *** [CMakeFiles/cleanup_system.dir/all] Error 2
>> epd-make[1]: *** [CMakeFiles/run_as_user.dir/rule] Error 2
>> epd-make: *** [run_as_user] Error 2
>>
>>
>> Does it mean that I have something which is not portable in my
>> CMakeLists?
>>
>> The solution might be remove the MinGW bin from the path of course,
>> but I would lose the nice commands from each shell
>> and I would also like to understand what is going on..
> The MingW platform file is explicitly programmed to reject MingW bash.
>
> Bill Hoffman implicitly rejected my offer to provide a patch to enable a
> new generator as of CMake 2.6.2:
> http://public.kitware.com/Bug/view.php?id=7870 . Without a policy
> reversal on his part, I would assume this platform (which is also mine)
> is intentionally unsupported.
>

gmake behaves differently if /bin/sh is in the PATH.  The makefiles for 
MinGW Makefiles are written for gmake running in the mode where it does 
not have /bin/sh.   The makefiles for Msys Makefiles are written so that 
they work with /bin/sh mode of gmake.   It all has to do with which 
shell is running the commands from gmake.  In the MinGW case, it is 
using a windows cmd.com shell, and in the Msys case it is using /bin/sh. 
  They are of course very different.  There is no way to force gmake to 
use a particular shell, it is all based on what is in the PATH.

About bug 7870, I am not sure that I understood that you were proposing 
a new generator.  I thought the bug was more about getting bootstrap to 
work.   It does seem that there is an issue with allowing make.exe to 
work.   I think if you set CMAKE_MAKEPROGRAM to make.exe it should work. 
  A patch that found different make.exe or make-mingw and then tested 
them would not be rejected.   I still don't see how we can avoid having 
separate generators for MinGW and Msys, and I certainly don't think a 
third one would help reduce confusion.

Also, I think someone might have fixed the bootstrap issues with Msys at 
this point, but I am not sure... A lot has changed since 2008 when that 
bug was created...

-Bill



More information about the CMake mailing list