[CMake] mingw vs MSYS makefiles

[David Cole]

On Thu, Feb 23, 2012 at 2:46 PM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> 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
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake


Just an FYI:

The bootstrap test does run on this dashboard, which uses the "MSYS
Makefiles" generator:

  http://open.cdash.org/buildSummary.php?buildid=2032185

  http://open.cdash.org/testDetails.php?test=136299358&build=2032185