Discussion:
[CMake] Detecting MinGW MSYS or Cygwin unix style file system
Brandon J. Van Every
2005-11-22 14:35:19 UTC
Permalink
Hi, I'm going up the CMake Windows learning curve on behalf of Chicken
Scheme.
http://www.call-with-current-continuation.org/index.html
I have read the archives quite a bit and I think it's time to ask the
question.

I notice that on Windows the default CMAKE_INSTALL_PREFIX is "C:/Program
Files". However, this doesn't actually make sense to a MinGW user
employing MSYS. MSYS implements a unix-style file system, so a proper
prefix would more likely be "/usr/local". However, the wrinkle is it's
also perfectly legitimate to use MinGW sans MSYS, and install things to
"C:/Program Files" in the normal Windows way. It's really MSYS that's
the dependency here, not MinGW. And so, I would like to detect MSYS and
"do the right thing" for people who are using Windows as a Unix-alike.
Not because I love Unix, but because I want to keep my MSYS and "normal
Windows" environments completely separate from each other. When people
try out Chicken, I want to be able to ask "are you using the MinGW, the
Cygwin, or the VC++ build?" and not have there be any confusion about
what got installed where.

Does a similar issue pertain to Cygwin? Maybe not, as the archives
seemed to indicate that it may use /usr/local by default. I am not
wishing to try this out if I can avoid it. :-) Aside from being highly
biased towards MinGW support issues, it happens that Eclipse gets messed
up if both are on one's system.

Gleaning knowledge from the archives, I have created a PreLoad.cmake
which successfully detects MSYS. My understanding is that this command
must be in PreLoad.cmake, that it cannot just be in CMakeLists.txt, as
it must be set before anything else happens. Correct?

IF(WIN32)
IF("$ENV{OSTYPE}" STREQUAL "msys")
SET(CMAKE_INSTALL_PREFIX "/usr/local" CACHE PATH
"MSYS default install path")
ENDIF("$ENV{OSTYPE}" STREQUAL "msys")
ENDIF(WIN32)

I am wondering if CMake has its own, native, more reliable way of doing
this. If it doesn't, I'm thinking it should, because MinGW and MSYS are
like bread and butter, even if bread can be eaten without butter. :-)
I am also wondering if anyone knows if OSTYPE is a reliable indicator.
I just looked at what was in the environment and figured, heh, this
looks like it'll work.


Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Brad King
2005-11-22 16:49:46 UTC
Permalink
Post by Brandon J. Van Every
I notice that on Windows the default CMAKE_INSTALL_PREFIX is "C:/Program
Files". However, this doesn't actually make sense to a MinGW user
employing MSYS. MSYS implements a unix-style file system, so a proper
prefix would more likely be "/usr/local".
CMake 2.0 used to use /usr/local as the default prefix even on Windows.
This was fixed for CMake 2.2 to be a more windows-like path. We
should improve the fix to work with MSys, though. Please submit a bug
report here:

http://www.cmake.org/Bug
Post by Brandon J. Van Every
Does a similar issue pertain to Cygwin? Maybe not, as the archives
seemed to indicate that it may use /usr/local by default.
No, because CMake builds natively under cygwin as a cygwin program.
Separate CMake builds must be used for Windows and Cygwin, but the same
CMake build can be used for Windows and MinGW/MSYS.
Post by Brandon J. Van Every
Gleaning knowledge from the archives, I have created a PreLoad.cmake
which successfully detects MSYS. My understanding is that this command
must be in PreLoad.cmake, that it cannot just be in CMakeLists.txt, as
it must be set before anything else happens. Correct?
IF(WIN32)
IF("$ENV{OSTYPE}" STREQUAL "msys")
SET(CMAKE_INSTALL_PREFIX "/usr/local" CACHE PATH
"MSYS default install path")
ENDIF("$ENV{OSTYPE}" STREQUAL "msys")
ENDIF(WIN32)
That looks fine to me. Please include it in the bug report. It doesn't
matter if OSTYPE is set on other platforms or not. As long as it is set
for msys then it can be used to detect msys.

-Brad
William A. Hoffman
2005-11-22 22:33:20 UTC
Permalink
Hi, I'm going up the CMake Windows learning curve on behalf of Chicken Scheme.
http://www.call-with-current-continuation.org/index.html
I have read the archives quite a bit and I think it's time to ask the question.
I notice that on Windows the default CMAKE_INSTALL_PREFIX is "C:/Program Files". However, this doesn't actually make sense to a MinGW user employing MSYS. MSYS implements a unix-style file system, so a proper prefix would more likely be "/usr/local". However, the wrinkle is it's also perfectly legitimate to use MinGW sans MSYS, and install things to "C:/Program Files" in the normal Windows way. It's really MSYS that's the dependency here, not MinGW. And so, I would like to detect MSYS and "do the right thing" for people who are using Windows as a Unix-alike.
Not because I love Unix, but because I want to keep my MSYS and "normal Windows" environments completely separate from each other. When people try out Chicken, I want to be able to ask "are you using the MinGW, the Cygwin, or the VC++ build?" and not have there be any confusion about what got installed where.
This is a bug, for MINGW, it should not be "C:/Program Files". Please create a bug report
www.cmake.org/Bug
Does a similar issue pertain to Cygwin? Maybe not, as the archives seemed to indicate that it may use /usr/local by default. I am not wishing to try this out if I can avoid it. :-) Aside from being highly biased towards MinGW support issues, it happens that Eclipse gets messed up if both are on one's system.
For cygwin, you should use the cmake built for cygwin, it is available via the cygwin setup program. It will use unix paths.
Gleaning knowledge from the archives, I have created a PreLoad.cmake which successfully detects MSYS. My understanding is that this command must be in PreLoad.cmake, that it cannot just be in CMakeLists.txt, as it must be set before anything else happens. Correct?
IF(WIN32)
IF("$ENV{OSTYPE}" STREQUAL "msys")
SET(CMAKE_INSTALL_PREFIX "/usr/local" CACHE PATH
"MSYS default install path")
ENDIF("$ENV{OSTYPE}" STREQUAL "msys")
ENDIF(WIN32)
I am wondering if CMake has its own, native, more reliable way of doing this. If it doesn't, I'm thinking it should, because MinGW and MSYS are like bread and butter, even if bread can be eaten without butter. :-)
I am also wondering if anyone knows if OSTYPE is a reliable indicator.
I just looked at what was in the environment and figured, heh, this looks like it'll work.
Anther way to do this until the bug is fixed is just to add the following into the chicken cmakelist file:

IF(MINGW)
SET(CHICKEN_INSTALL_PREFIX "/usr/local" CACHE PATH "Mingw default install path")
ELSE(MINGW)
SET(CHICKEN_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX} CACHE PATH "default install path")
ENDIF(MINGW)
SET(CMAKE_INSTALL_PREFIX ${CHICKEN_INSTALL_PREFIX} CACHE INTERNAL "")

This is a common way of overriding a cmake variable. It will hide the cmake variable CMAKE_INSTALL_PREFIX
and make it always the same as CHICKEN_INSTALL_PREFIX. I tested the above, and it sets the install
prefix to /usr/local if you pick "Unix Makefiles" from a CMakeSetup run from msys.

-Bill
Brandon J. Van Every
2005-11-23 03:21:02 UTC
Permalink
Post by William A. Hoffman
Hi, I'm going up the CMake Windows learning curve on behalf of Chicken Scheme.
http://www.call-with-current-continuation.org/index.html
I have read the archives quite a bit and I think it's time to ask the question.
I notice that on Windows the default CMAKE_INSTALL_PREFIX is "C:/Program Files". However, this doesn't actually make sense to a MinGW user employing MSYS. MSYS implements a unix-style file system, so a proper prefix would more likely be "/usr/local". However, the wrinkle is it's also perfectly legitimate to use MinGW sans MSYS, and install things to "C:/Program Files" in the normal Windows way. It's really MSYS that's the dependency here, not MinGW. And so, I would like to detect MSYS and "do the right thing" for people who are using Windows as a Unix-alike.
Not because I love Unix, but because I want to keep my MSYS and "normal Windows" environments completely separate from each other. When people try out Chicken, I want to be able to ask "are you using the MinGW, the Cygwin, or the VC++ build?" and not have there be any confusion about what got installed where.
This is a bug, for MINGW, it should not be "C:/Program Files". Please create a bug report
www.cmake.org/Bug
Actually, for *MINGW* I don't think so. MinGW links against msvcrt.dll,
available on any Windows system. As I said above, it is perfectly
legitimate to use MinGW to create "normal" Windows .exe's that are
installed in normal Windows places. For instance, the game Freeciv gets
the bulk of its development done on Linux, but also has a MinGW build
that installs just like any other Windows game in the usual C:/Program
Files. This isn't the right behavior for *MSYS*, however, as *MSYS* is
implementing a Unix environment. It's important to think of MSYS as
separate software distinct from MinGW. Chicken Scheme users, for
instance, might not install MSYS, they might work with MinGW straight
from the standard Windows command prompt.

I will be filing the various bugs though.
Post by William A. Hoffman
Gleaning knowledge from the archives, I have created a PreLoad.cmake which successfully detects MSYS. My understanding is that this command must be in PreLoad.cmake, that it cannot just be in CMakeLists.txt, as it must be set before anything else happens. Correct?
IF(WIN32)
IF("$ENV{OSTYPE}" STREQUAL "msys")
SET(CMAKE_INSTALL_PREFIX "/usr/local" CACHE PATH
"MSYS default install path")
ENDIF("$ENV{OSTYPE}" STREQUAL "msys")
ENDIF(WIN32)
I am wondering if CMake has its own, native, more reliable way of doing this. If it doesn't, I'm thinking it should, because MinGW and MSYS are like bread and butter, even if bread can be eaten without butter. :-)
I am also wondering if anyone knows if OSTYPE is a reliable indicator.
I just looked at what was in the environment and figured, heh, this looks like it'll work.
IF(MINGW)
SET(CHICKEN_INSTALL_PREFIX "/usr/local" CACHE PATH "Mingw default install path")
ELSE(MINGW)
SET(CHICKEN_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX} CACHE PATH "default install path")
ENDIF(MINGW)
SET(CMAKE_INSTALL_PREFIX ${CHICKEN_INSTALL_PREFIX} CACHE INTERNAL "")
This is a common way of overriding a cmake variable. It will hide the cmake variable CMAKE_INSTALL_PREFIX
and make it always the same as CHICKEN_INSTALL_PREFIX. I tested the above, and it sets the install
prefix to /usr/local if you pick "Unix Makefiles" from a CMakeSetup run from msys.
Good trick, although stylistically I prefer the PreLoad.cmake version
that is not Chicken specific. It may increase the odds of the problem
being ironed out, and also elevate Chicken people's CMake skills. I
suppose the above could be abstracted to ANYPROJECT_INSTALL_PREFIX with
a few more commands.


Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
David Cole
2005-11-23 13:51:49 UTC
Permalink
To me, the very fact that you are targeting Windows indicates that a
*default* value of "C:/Program Files" is entirely appropriate.

Anything else is non-default and project-specific. (And CMake
provides the facility for you to set this value on a per-project basis.)

Why should what build system you use be coupled to the default value
for the install target? The build system and the build products are
two different things. CMake's default value for something should be
appropriate for the majority of its users. I would argue that most
folks are building Windows targeted projects, not MSYS targeted
projects...

Just my 2 cents...


David
Post by Brandon J. Van Every
Post by William A. Hoffman
Hi, I'm going up the CMake Windows learning curve on behalf of Chicken Scheme.
http://www.call-with-current-continuation.org/index.html
I have read the archives quite a bit and I think it's time to ask the question.
I notice that on Windows the default CMAKE_INSTALL_PREFIX is "C:/
Program Files". However, this doesn't actually make sense to a
MinGW user employing MSYS. MSYS implements a unix-style file
system, so a proper prefix would more likely be "/usr/local".
However, the wrinkle is it's also perfectly legitimate to use
MinGW sans MSYS, and install things to "C:/Program Files" in the
normal Windows way. It's really MSYS that's the dependency here,
not MinGW. And so, I would like to detect MSYS and "do the right
thing" for people who are using Windows as a Unix-alike. Not
because I love Unix, but because I want to keep my MSYS and
"normal Windows" environments completely separate from each
other. When people try out Chicken, I want to be able to ask
"are you using the MinGW, the Cygwin, or the VC++ build?" and not
have there be any confusion about what got installed where.
This is a bug, for MINGW, it should not be "C:/Program Files".
Please create a bug report
www.cmake.org/Bug
Actually, for *MINGW* I don't think so. MinGW links against
msvcrt.dll, available on any Windows system. As I said above, it
is perfectly legitimate to use MinGW to create "normal"
Windows .exe's that are installed in normal Windows places. For
instance, the game Freeciv gets the bulk of its development done on
Linux, but also has a MinGW build that installs just like any other
Windows game in the usual C:/Program Files. This isn't the right
behavior for *MSYS*, however, as *MSYS* is implementing a Unix
environment. It's important to think of MSYS as separate software
distinct from MinGW. Chicken Scheme users, for instance, might not
install MSYS, they might work with MinGW straight from the standard
Windows command prompt.
I will be filing the various bugs though.
Post by William A. Hoffman
Gleaning knowledge from the archives, I have created a
PreLoad.cmake which successfully detects MSYS. My understanding
is that this command must be in PreLoad.cmake, that it cannot
just be in CMakeLists.txt, as it must be set before anything else
happens. Correct?
IF(WIN32)
IF("$ENV{OSTYPE}" STREQUAL "msys")
SET(CMAKE_INSTALL_PREFIX "/usr/local" CACHE PATH
"MSYS default install path")
ENDIF("$ENV{OSTYPE}" STREQUAL "msys")
ENDIF(WIN32)
I am wondering if CMake has its own, native, more reliable way of
doing this. If it doesn't, I'm thinking it should, because MinGW
and MSYS are like bread and butter, even if bread can be eaten
without butter. :-) I am also wondering if anyone knows if
OSTYPE is a reliable indicator. I just looked at what was in the
environment and figured, heh, this looks like it'll work.
Anther way to do this until the bug is fixed is just to add the
IF(MINGW)
SET(CHICKEN_INSTALL_PREFIX "/usr/local" CACHE PATH "Mingw
default install path")
ELSE(MINGW)
SET(CHICKEN_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX} CACHE PATH "default install path")
ENDIF(MINGW)
SET(CMAKE_INSTALL_PREFIX ${CHICKEN_INSTALL_PREFIX} CACHE INTERNAL "")
This is a common way of overriding a cmake variable. It will
hide the cmake variable CMAKE_INSTALL_PREFIX
and make it always the same as CHICKEN_INSTALL_PREFIX. I tested
the above, and it sets the install
prefix to /usr/local if you pick "Unix Makefiles" from a
CMakeSetup run from msys.
Good trick, although stylistically I prefer the PreLoad.cmake
version that is not Chicken specific. It may increase the odds of
the problem being ironed out, and also elevate Chicken people's
CMake skills. I suppose the above could be abstracted to
ANYPROJECT_INSTALL_PREFIX with a few more commands.
Cheers,
Brandon Van Every
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
_______________________________________________
CMake mailing list
http://www.cmake.org/mailman/listinfo/cmake
Brandon J. Van Every
2005-11-23 15:19:27 UTC
Permalink
Post by David Cole
To me, the very fact that you are targeting Windows indicates that a
*default* value of "C:/Program Files" is entirely appropriate.
Plainly, MSYS is not "Windows," it is a Unix lookalike. No different in
principle than Cygwin shell and filesystem. You are familiar with
those, right? Pathnames go /// instead of the usual Windows \\\,
everything is /usr/bin and so forth, all standard Unix tools are present
and accounted for....
Post by David Cole
I would argue that most folks are building Windows targeted projects,
not MSYS targeted projects...
That misses the point. MSYS users are building MSYS projects, just like
any other Unix source code build.

Do not confuse MinGW for MSYS. MinGW is a compiler. MSYS is an OS
environment.


Cheers,
Brandon Van Every
Brandon J. Van Every
2005-11-23 15:25:02 UTC
Permalink
Post by David Cole
To me, the very fact that you are targeting Windows indicates that a
*default* value of "C:/Program Files" is entirely appropriate.
MSYS is not "Windows." It is a Unix workalike, with forward slash
pathnames, its own / root directory structure, Unix tools in abundance,
etc. Do not confuse MinGW and MSYS. MinGW is a compiler, MSYS is an OS
environment. Neither requires the other, although they are often used
together.
Post by David Cole
CMake's default value for something should be appropriate for the
majority of its users.
The majority of MSYS users expect /usr/local/. Hence, MSYS should be
detected and treated as its own beast, same as Cygwin shell is. Here's
the basic difference between Cygwin and MSYS: the latter is better
licensed and worse packaged. Hopefully that fault will change in time.

Gotta go fly away and eat a turkey somewhere distant.


Cheers,
Brandon Van Every
William A. Hoffman
2005-11-23 16:25:52 UTC
Permalink
<html>
<body>
At 10:19 AM 11/23/2005, Brandon J. Van Every wrote:<br>
<blockquote type=cite class=cite cite="">David Cole wrote:<br><br>
<blockquote type=cite class=cite cite="">To me, the very fact that you
are targeting Windows indicates that a&nbsp; <br>
*default* value of &quot;C:/Program Files&quot; is entirely appropriate.
</blockquote><br>
Plainly, MSYS is not &quot;Windows,&quot; it is a Unix lookalike.&nbsp;
No different in principle than Cygwin shell and filesystem.&nbsp; You are
familiar with those, right?&nbsp; Pathnames go /// instead of the usual
Windows \\\, everything is /usr/bin and so forth, all standard Unix tools
are present and accounted for....<br><br>
<blockquote type=cite class=cite cite="">I would argue that most&nbsp;
folks are building Windows targeted projects, not MSYS targeted&nbsp;
projects...</blockquote>That misses the point.&nbsp; MSYS users are
building MSYS projects, just like any other Unix source code
build.<br><br>
Do not confuse MinGW for MSYS.&nbsp; MinGW is a compiler.&nbsp; MSYS is
an OS environment.</blockquote><br>
I am not sure I agree.&nbsp; <br><br>

Loading...