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

[Gonzalo Garramuño]

Bill Hoffman wrote:

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

I disagree.  You can infer how MinGW is being used by looking at the 
user's environment.  /usr/local is more tricky but can also be inferred. 
  More below.

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

Okay so far.

> What you want to do is extend the 
> msys environment with extra POSIX compatible tools.   

No.  I was just trying to compile cmake (or other stuff) under msys and 
have it behave like all other (subset of) autotools libraries or 
executables that can be compiled under such environment.  All of these 
get compiled and installed under MSYS's /usr/local root, not under 
$PROGRAMFILES.

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

AFAIK, no.  If my understanding of MSYS/MinGW is correct, there's no 
extra POSIX compatibility library.  The POSIX compatibility comes from 
the limited POSIX compatibility provided by the win32api and the msvcrt 
DLL.  This is one of the things it distinguishes it from cygwin, where 
the cygwin.dll does indeed try to have a 1-to-1 correspondence with 
POSIX (and some Linux internals too).

--- digression---
Currently, neither cygwin nor mingw support sym links (as they are still 
constrained by what pre-windows vista supports).  Cygwin might support 
mount points other than windows ones (like NFS), but not sure.  MinGW 
certainly does not (only windows A: to Z: drives).
The only magic msys utilities like bash perform is modifying the PATH 
variable for Windows to make /C/ become C:\ and '/' become MSYSROOT\.

---back on topic--
To do what I was suggesting (properly), a MinGW cmake would have to use 
*Windows API* calls to find what its process is child of (like cmd.exe, 
command.com, bash.exe, rxvt.exe, etc.) and then act accordingly to that.

As that may be tricky to do, I suggested a simpler (somewhat hack) 
approach of using the environment variable called "SHELL" which SHOULD 
be defined under any kind of Unix shell to a valid shell and SHOULD NOT 
be defined under cmd.exe, command.com or if cmake+mingw gets called 
directly by some other windows build environment or utility.  The "TERM" 
environment variable could also probably be used.

As far as finding the MSYS root, that is indeed tricky as the MSYS.bat 
file does not by default seem to define any environment variable for it.

Currently the MSYS environment is often installed with InnoSetup and a 
registry entry for it exists in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
MSYS-1.0_is1 or similar

In the case no installer was used or you don't want to tie yourself to 
InnoSetup, it can still be inferred from the user environment.

For one, the PATH variable HAS to contain the unix utilities somewhere. 
  The path to some common unix utility like 'ls' or 'sh' or 'make' could 
be used (which should be $MSYSROOT\bin but could also potentially be 
$MSYSROOT\usr\local\bin).

If addition, you probably still want to have an environment variable or 
CMAKE variable to specify the root of msys in case cmake 'guesses' 
incorrectly.



-- 
Gonzalo Garramuño
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy