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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
