Quantcast

mingw vs MSYS makefiles

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

mingw vs MSYS makefiles

Andrea Crotti
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Kenneth Boyd
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.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

David Cole
On Thu, Feb 23, 2012 at 2:46 PM, Bill Hoffman <[hidden email]> 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
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Kenneth Boyd
In reply to this post by Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Kenneth Boyd
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Bill Hoffman
In reply to this post by Kenneth Boyd
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Alan W. Irwin
In reply to this post by Kenneth Boyd
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. 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Alan W. Irwin
In reply to this post by Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Bill Hoffman
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
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Kenneth Boyd
In reply to this post by Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Bill Hoffman
In reply to this post by Andrea Crotti
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Kenneth Boyd
In reply to this post by Alan W. Irwin
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 AT&T, 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Kenneth Boyd
In reply to this post by Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Alan W. Irwin
In reply to this post by Bill Hoffman
On 2012-02-23 17:49-0500 Bill Hoffman wrote:

> 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.

Hi Bill:

Thanks very much for that most enlightening additional background
information.  I had no idea that the two versions of make were so
similar and that the sh.exe distinction was made upstream of those two
versions.

Also, that quote implies I could get a very different build result
even with "MSYS Makefiles" if I rename sh.exe to something else.

So to address that concern as well as the original poster's concern
(and mine) that we still want access to the MSYS tools with the "MinGW
Makefiles" generator, it appears the correct thing to do is to create
two versions of MinGW/msys/1.0/bin/ (one with sh.exe left as is, the
other one with it renamed or removed).  Then for the "MinGW Makefiles"
generator put the version of MinGW/msys/1.0/bin on your path with the
renamed sh.exe which forces use of win32 make mode which uses
"intermediate batch files for command processing". For the "MSYS
Makefiles" generator put the original MinGW/msys/1.0/bin including
sh.exe on your PATH so that everything is built using sh.exe commands.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Andrea Crotti
In reply to this post by Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: mingw vs MSYS makefiles

Bill Hoffman
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
Loading...