[CMake] MSYS and CMake placeholder

Brandon J. Van Every bvanevery at gmail.com
Sat Dec 10 03:00:13 EST 2005


William A. Hoffman wrote:
 >At 03:02 AM 11/30/2005, Brandon J. Van Every wrote:

>
>  
>
>>Hrm.  Well, compiling a second time doesn't solve the problem.  I guess I'll have to investigate the MSYS theory of operation, and also the CMake cygwin build.  I will wager, IF(UNIX) is problematic for MSYS because it is both a Windows system and Unix-like.
>>    
>>
>Actually, I don't think there is any IF(UNIX) stuff in the FIND stuff.  
>However, I do think this might be the answer to our question about the
>correct install path.  I think you have to do some special stuff to create
>an MSYS executable, but just compiling within the MSYS environment does not
>make a program aware of the /usr/local file system that MSYS creates.  So, I don't think
>you would want to install programs into a directory that you could not find....
>With cygwin, if you link with the cygwin runtime, your program automatically
>knows about cygwin mount points, symlinks, etc because it gets a different libc.
>However, with MSYS you link with the native Microsoft libraries and your program knows 
>nothing about the special files that MSYS uses to simulate a UNIX file system.
>
>Also, for cygwin, CMake defines UNIX as well as WIN32.  


I've looked into MSYS some more.  I've discovered or concluded the 
following:

- MSYS is actually a fork of the Cygwin Posix shell
- linkage with msys-1.0.dll is probably needed to solve pathing problems
- as a Cygwin shell derivative, msys-1.0.dll is under GPL.
- there is a SDK for working with MSYS, but it is in alpha
- a "normal" CMakeSetup does not know about any MSYS environment variables
- this means CMakeSetup has a futzy learning curve with regards to 
MSYS.  One must create a separate environment outside of MSYS, generate 
Unix Makefiles, then use the results inside of MSYS
- the "right thing to do" is to create a MSYS-specific CMake and CCMake
- those binaries would be under GPL, which is the case for Cygwin CMake 
already, so would be handled in the same manner.
- this is non-trivial work, for me at least.  Might be trivial for 
someone else, but the alpha quality SDK represents both a learning curve 
and risk.
- MSYS core developer philosophy is indeed minimal, and archives suggest 
they will adamantly oppose anyone's attempt to turn it into another 
Cygwin.  However, the main purpose of MSYS is to run the GNU autoconf 
toolchain.  Since CMake's purpose is to provide something autoconf-like 
that is truly cross-platform, it may be strategically valuable to court 
these guys and get them to endorse first class CMake support.

However, given the above, I am putting this project aside for now.  As 
it happens, making CMake and MSYS play nicely together is not core to my 
current projects, and I am very pressed for time.  I'm leaving this as a 
placeholder for those who might peruse the archive looking for the same 
answers.  That may even be myself someday.  I tend to forget the ground 
I've covered, crank up Google a year later, and find my own posts.  Then 
I'm usually depressed because the ball usually hasn't moved forwards on 
whatever I thought would have been "a good idea for the world."  :-(  Oh 
well, such is the way of open source!  I can only keep going with so 
many things; same story for everyone really.

I will continue to contribute to the refinement of Chicken Scheme's 
CMake builds, however.
http://www.call-with-current-continuation.org/index.html


Cheers,
Brandon J. Van Every
   (cruise (director (of SeaFunc)
           '(Seattle Functional Programmers)))
http://groups.yahoo.com/group/SeaFunc





More information about the CMake mailing list