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
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
