[CMake] CMake2.5 - wrong default install location for mingw

[Bill Hoffman]

Gonzalo Garramuño wrote:
> Bill Hoffman wrote:
>> That is not a bug.  MSYS in its "charter" explicitly says it does not 
>> want to become a new cygwin.  The tools in msys are available only for 
>> support of the compiler tool chain. The main goal is to build native 
>> windows applications with the mingw tool chain.  If you want posix 
>> applications you should be using cygwin.
>>
> 
> Well, yes, the problem with that theory or that take on mingw's charter 
> is that:
> 
> a) All unix autotools utilities (or other libs like ffmpeg) built under 
> mingw/msys will not install in $PROGRAMFILES, which leads to cmake's 
> approach being totally backwards with the rest of msys.
> 

CMake is not an autotools utility.

> The proper approach for mingw with cmake should be to detect the 
> environment the user is using.  To me the simplest approach to doing 
> that would really be to check if $SHELL is defined.  If it is, it should 
> default to a Unix install location of /usr/local (ie MingGW root's 
> /usr/local).  If it is not defined, it should default to a windows 
> install of $PROGRAMFILES.
> 

There is no way to tell at cmake time what the user intends to use the 
code for.  If the user of cmake is building a windows app, which is the 
standard use case for MinGW, then it you don't want /usr/local.  Not 
only that, but cmake does not even know what /usr/local is, as it does 
not link to the msys run time.   I guess what you really want is an msys 
version of cmake.   This would be much like the cygwin version of cmake, 
it would be used to build msys binaries.  I have not attempted to build 
such a version of cmake, currently such a thing does not exist.

> b) cygwin's approach is sadly bloated and uses a somewhat inefficient 
> approach that also forces you to depend on cygwin.dll and the microsoft 
> runtimes (mingw only depends on an outdated microsoft runtime).  That 
> makes it not suitable for a lot of stuff (Mind you, I've used cygwin for 
> 5+ years to have a basic unix shell environment on windows and for that 
> I'm eternally thankful but mainly because mingw as a shell environment 
> back then was pitiful).  Now the combo of mingw-msys has evolved to be a 
> superior solution for me (and I don't need X11 gui tools on windows 
> which mingw will probably never provide, which is how I interpret 
> mingw's charter).
> 

Let's look at the www.mingw.org web page:


MinGW: A collection of freely available and freely distributable Windows 
specific header files and import libraries combined with GNU toolsets 
that allow one to produce native Windows programs that do not rely on 
any 3rd-party C runtime DLLs.

MSYS: A Minimal SYStem to provide POSIX/Bourne configure scripts the 
ability to execute and create a Makefile used by make.


The clear goal is to produce native Windows programs, and to support the 
autotools make toolchain with enough programs to run make in order to 
produce native windows applications.   What you want to do is extend the 
msys environment with extra POSIX compatible tools.   To do that cmake 
would have to link to the MSYS run time library in order to understand 
things like sym links and mount points.

-Bill