[CMake] Detecting MinGW MSYS or Cygwin unix style file system

David Cole david.cole at kitware.com
Wed Nov 23 08:51:49 EST 2005


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

On Nov 22, 2005, at 10:21 PM, Brandon J. Van Every wrote:

> William A. Hoffman wrote:
>
>> At 09:35 AM 11/22/2005, Brandon J. Van Every wrote:
>>
>>> 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.
>
>>
>>> 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.
>>
> 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
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake



More information about the CMake mailing list