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
