[CMake] mingw vs MSYS makefiles

[Alan W. Irwin]

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
__________________________