Re: [CMake] mingw vs MSYS makefiles
On 02/23/2012 10:55 PM, Bill Hoffman wrote: On 2/23/2012 6:20 AM, Andrea Crotti wrote: I don't think anyone really addressed your question. Your question seems to have taken on a whole new life The problem seems to be that your cmake file is creating makefiles that use a python program in them. For some reason python is not working from an msys shell for you. You should debug that, and try to figure out how to get a python that does work, or figure out why this python is failing under msys. Moral of the story, don't depend on python in your build, use cmake scripts if possible, or c programs that you build :) Ideally yes, unfortunately it's not really possible to avoid the python call, without rewriting a lot of code in CMake/C (which is not a good idea). I will check what is the requirement, if the MinGW make is fine then I'll just use that otherwise I'll debug the problem with the MSYS.. -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/24/2012 5:25 AM, Andrea Crotti wrote: Ideally yes, unfortunately it's not really possible to avoid the python call, without rewriting a lot of code in CMake/C (which is not a good idea). I will check what is the requirement, if the MinGW make is fine then I'll just use that otherwise I'll debug the problem with the MSYS.. Well, the problem is something is calling python with the wrong path, it is using the msys path, but the calling program can not start python from /c/python. From what you sent it is hard to tell what the calling program is that is trying to launch python. You should look at the generated Makefiles and see what is going on. Also, how is python called from your CMake code? -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
[CMake] mingw vs MSYS makefiles
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.. Thanks, Andrea -- 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
Re: [CMake] mingw vs MSYS makefiles
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
Re: [CMake] mingw vs MSYS makefiles
On Thu, Feb 23, 2012 at 2:46 PM, Bill Hoffman bill.hoff...@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=136299358build=2032185 -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 1:46 PM, Bill Hoffman wrote: 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. Right. Unfortunately, I have MingW installed from official tarballs, rather than the MSYS executable installer; the MSYS installer *.exe critically failed for me back in 2001, so once I got a working install procedure from official tarballs I stuck with it. What is happening is that I have an official MingW /bin/sh in my path (which triggers MSYS), but the pathnames required by windows-side tools such as MingW32 gcc are still Windows-ish (MingW). 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. Bootstrap failed at the time because there was no generator that worked. The workaround indicated what was needed was a third generator (as MingW without bash in path is also a valid install method). 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. Ok. 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. I'm assuming that the Msys generator is intended for the results of the MSYS installer *.exe . As such, I'd prefer to assume the current MSYS generator is known-good for that case. My impression (please correct if inaccurate) is that it would be preferable to have the final patch augment the MSYS generator to discern which filepath convention is expected. Further discussion looks like it belongs on the CMake-developers list. 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... Right, will recheck that before proceeding. Kenneth -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 2:40 PM, Kenneth Boyd wrote: On 2/23/2012 1:46 PM, Bill Hoffman wrote: 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. I'm assuming that the Msys generator is intended for the results of the MSYS installer *.exe . David Cole has confirmed what I expected: that the MSYS generator is passing its tests currently ( http://open.cdash.org/buildSummary.php?buildid=2032185 ). That expectation is why I was considering a third generator. As such, I'd prefer to assume the current MSYS generator is known-good for that case. ... Kenneth -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 3:40 PM, Kenneth Boyd wrote: On 2/23/2012 1:46 PM, Bill Hoffman wrote: Right. Unfortunately, I have MingW installed from official tarballs, rather than the MSYS executable installer; the MSYS installer *.exe critically failed for me back in 2001, so once I got a working install procedure from official tarballs I stuck with it. What is happening is that I have an official MingW /bin/sh in my path (which triggers MSYS), but the pathnames required by windows-side tools such as MingW32 gcc are still Windows-ish (MingW). AFAIK, if /bin/sh is in your PATH gmake goes into shell mode and you can not use windows style shell stuff in the makefile. If you take out the check that I put in, it should fail in some other way. I put the check in early with a message to avoid people getting the weird errors later. 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. Ok. 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. I'm assuming that the Msys generator is intended for the results of the MSYS installer *.exe . As such, I'd prefer to assume the current MSYS generator is known-good for that case. My impression (please correct if inaccurate) is that it would be preferable to have the final patch augment the MSYS generator to discern which filepath convention is expected. I don't see what case your 3rd generator will handle. Seems to me there are only two cases regardless of how it was installed: 1. you have /bin/sh in your PATH and gmake runs commands via /bin/sh 2. you do not have /bin/sh in your PATH and gmake runs commands via the native windows shell. I wonder if the plain Unix Makefiles generator would work for you? -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
Re: [CMake] mingw vs MSYS makefiles
On 2012-02-23 14:40-0600 Kenneth Boyd wrote: On 2/23/2012 1:46 PM, Bill Hoffman wrote: 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. Right. Unfortunately, I have MingW installed from official tarballs, rather than the MSYS executable installer; the MSYS installer *.exe critically failed for me back in 2001, so once I got a working install procedure from official tarballs I stuck with it. What is happening is that I have an official MingW /bin/sh in my path (which triggers MSYS), but the pathnames required by windows-side tools such as MingW32 gcc are still Windows-ish (MingW). 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. Bootstrap failed at the time because there was no generator that worked. The workaround indicated what was needed was a third generator (as MingW without bash in path is also a valid install method). 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. Ok. 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. I'm assuming that the Msys generator is intended for the results of the MSYS installer *.exe . As such, I'd prefer to assume the current MSYS generator is known-good for that case. My impression (please correct if inaccurate) is that it would be preferable to have the final patch augment the MSYS generator to discern which filepath convention is expected. Further discussion looks like it belongs on the CMake-developers list. 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... Right, will recheck that before proceeding. Both the MSYS Makefiles and MinGW Makefiles generators have worked for me for a fairly recent version (20110802) of MinGW + MSYS installed with the automatic installer. For the latter case I renamed sh.exe to something else to keep sh.exe off the PATH. To answer the original poster that rename (rather than manipulating the PATH) allowed me to keep bash.exe and other useful MSYS tools used in the PLplot test suite on the PATH. N.B. these good results were for the wine version of Windows rather than the Microsoft version, but I doubt something would work on the wine platform that did not work on Microsoft Windows. Of course, there are still plenty of things that work on Microsoft Windows that do not work on wine, but typically those differences (which continue to be chased down and fixed by the wine developers) tend to be important only for high-end applications as opposed to relatively low-level build tools such CMake, MinGW, and MSYS. Of course, the other principal issue with a Windows build environment (whether wine or Microsoft) is the chain of library dependencies that are often required for free and open software. I am sure there is a statement out there somewhere on the web detailing the exact MinGW versions where the MinGW ABI has been changed, but I haven't found such a statement so to be paranoid on that issue I tend to build all dependencies from scratch using the same version of MinGW that I use for my package build. CMake helps with lots of those builds, but nevertheless those builds take quite an effort for each free and open software project. Thus, it's a real shame nobody has yet dealt with that issue by putting together a full distribution based on MinGW + MSYS where you could be sure the MinGW ABI is consistent for all libraries. Before anybody answers with Cygwin my understanding from reading http://www.mingw.org is the MinGW and MSYS developers forked their development from Cygwin long ago where the M stands for minimalist in the sense that they use Microsoft system libraries such as MSVCRT.DLL where possible as opposed to using special third-party system libraries written by Cygwin. Therefore a MinGW + MSYS distribution would be quite distinct from Cygwin and would also give that distribution some much-needed competition. It makes no sense to me that Linux has 500+ free and open software distributions while Windows only has one free and open software distribution. Alan __ Alan W.
Re: [CMake] mingw vs MSYS makefiles
On 2012-02-23 16:02-0500 Bill Hoffman wrote: Seems to me there are only two [MinGW/MSYS] cases regardless of how it was installed: 1. you have /bin/sh in your PATH and gmake runs commands via /bin/sh 2. you do not have /bin/sh in your PATH and gmake runs commands via the native windows shell. To add to the confusion, modern MinGW and MSYS have _two_ different make commands. One is called MinGW/bin/mingw32-make.exe and is used by the MinGW Makefiles generator while the other is called MinGW/msys/1.0/bin/make.exe and is used by the MSYS Makefiles generator. I presume those two executables correspond to various forks of gmake. There may be some other reason why they are different from one another, but one distinct possibility is that mingw32-make.exe now completely ignores the existence of sh.exe and exclusively uses the native windows shell. Bill, have you done any recent testing of the MinGW Makefiles case with MinGW/bin/mingw32-make.exe to see if it is still necessary that sh.exe not be on the PATH? If not, then the cmake test for sh.exe not on the PATH could be replaced by a check that the MinGW Makefiles generator finds and uses mingw32-make.exe while the MSYS Makefiles generator find and uses make.exe. As the original poster said, it is really nice to have MSYS on your PATH even if you are using the MinGW Makefiles generator. I work around this issue by renaming sh.exe to something else, but that workaround would not be necessary _if_ the existence of sh.exe on the PATH no longer affects what mingw32-make.exe does. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 5:18 PM, Alan W. Irwin wrote: make commands. One is called MinGW/bin/mingw32-make.exe and is used by the MinGW Makefiles generator while the other is called MinGW/msys/1.0/bin/make.exe and is used by the MSYS Makefiles generator. I presume those two executables correspond to various forks of gmake. The difference is the c runtime that they use. The MinGW one uses the Microsoft run time and so understands MS paths (c: and \). The msys one links to the msys runtime, and understands msys stuff like /c/foo instead of c:/foo. Both of these things aside, gmake upstream does look for sh: http://unxutils.sourceforge.net/ has the following info : From v3.77 upwards, make searches for a sh.exe on the path. If it does not find one, it switches to win32 make mode that is it uses intermediate batch files for command processing. So, both versions of gmake are actually the same source code but they are built with different c run time libraries. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 3:02 PM, Bill Hoffman wrote: On 2/23/2012 3:40 PM, Kenneth Boyd wrote: On 2/23/2012 1:46 PM, Bill Hoffman wrote: Right. Unfortunately, I have MingW installed from official tarballs, rather than the MSYS executable installer; the MSYS installer *.exe critically failed for me back in 2001, so once I got a working install procedure from official tarballs I stuck with it. What is happening is that I have an official MingW /bin/sh in my path (which triggers MSYS), but the pathnames required by windows-side tools such as MingW32 gcc are still Windows-ish (MingW). AFAIK, if /bin/sh is in your PATH gmake goes into shell mode and you can not use windows style shell stuff in the makefile. If you take out the check that I put in, it should fail in some other way. I put the check in early with a message to avoid people getting the weird errors later. If if does fail in some other way, then obviously the proposed patch isn't ready to submit ;) I'll include that as part of testing. The prototyping I did was sufficient to get CMake to bootstrap, so it should take a more complicated test case to trigger problems. 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. Ok. 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. I'm assuming that the Msys generator is intended for the results of the MSYS installer *.exe . As such, I'd prefer to assume the current MSYS generator is known-good for that case. My impression (please correct if inaccurate) is that it would be preferable to have the final patch augment the MSYS generator to discern which filepath convention is expected. I don't see what case your 3rd generator will handle. Seems to me there are only two cases regardless of how it was installed: 1. you have /bin/sh in your PATH and gmake runs commands via /bin/sh 2. you do not have /bin/sh in your PATH and gmake runs commands via the native windows shell. I need to handle /bin/sh in my PATH, without using CygWin-style paths that the MingW utilities cannot handle. I wonder if the plain Unix Makefiles generator would work for you? That should be retested, yes. Kenneth -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 6:20 AM, Andrea Crotti wrote: 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 I don't think anyone really addressed your question. Your question seems to have taken on a whole new life The problem seems to be that your cmake file is creating makefiles that use a python program in them. For some reason python is not working from an msys shell for you. You should debug that, and try to figure out how to get a python that does work, or figure out why this python is failing under msys. Moral of the story, don't depend on python in your build, use cmake scripts if possible, or c programs that you build :) -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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 3:50 PM, Alan W. Irwin wrote: Both the MSYS Makefiles and MinGW Makefiles generators have worked for me for a fairly recent version (20110802) of MinGW + MSYS installed with the automatic installer. For the latter case I renamed sh.exe to something else to keep sh.exe off the PATH. To answer the original poster that rename (rather than manipulating the PATH) allowed me to keep bash.exe and other useful MSYS tools used in the PLplot test suite on the PATH. N.B. these good results were for the wine version of Windows rather than the Microsoft version, but I doubt something would work on the wine platform that did not work on Microsoft Windows. Of course, there are still plenty of things that work on Microsoft Windows that do not work on wine, but typically those differences (which continue to be chased down and fixed by the wine developers) tend to be important only for high-end applications as opposed to relatively low-level build tools such CMake, MinGW, and MSYS. Ok. I have been using the manual install from tarballs since 2001; it has worked reasonably well on everything from Win95 to Win7. My main problems with this platform have to do with the FSF's elimination of the fork emulation in 2002 (negative interaction in licensing between GPL and ATT, the resulting binaries are not very distributable according to FSF). Kenneth -- 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
Re: [CMake] mingw vs MSYS makefiles
On 2/23/2012 4:55 PM, Bill Hoffman wrote: On 2/23/2012 6:20 AM, Andrea Crotti wrote: 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 I don't think anyone really addressed your question. Your question seems to have taken on a whole new life True. This kind of error is what happens when CygWin paths (MSYS generator) are fed into MingW utilities: the CreateProcess command from mscvrt.dll fails horribly. Python is probably installed at c:\Python25\python.exe ; /c/python25/python.exe is the CygWin path corresponding to that. The MingW bash is looking for c:\c\python25\python.exe rather than c:\python25\python.exe . Moral of the story, don't depend on python in your build, use cmake scripts if possible, or c programs that you build :) Ideally, yes. Kenneth -- 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
