Web lists-archives.com

AW: [Mingw-msys] Bison-2.0-MSYS.tar.gz

Bill Hoffman wrote:
> Just to be clear it is easy for both developers to change what the 
> default is for a package, and for end users to change the default if 
> they are building a package.  The only questions here, is what should 
> the default be for CMake when creating makefiles for msys.
Bill, you should also mention some more things about how cmake works and 
what's requested.

CMake provides generators that create makefiles or IDEs, like an 
autoconf on steroids. 

For MinGW, CMake provides both a "MinGW Generator" and a "MSYS 
Generator".   Unfortunately, both default to $PROGRAMFILES.  My request 
is to have the MSYS Generator default to /usr/local, while the MinGW one 
is left pointing to $PROGRAMFILES.  The MinGW defaults to mingw-make if 
found, if I'm not mistaken, which further avoids path issues.

CMake is oriented to development, not shipping products.  An additional 
CMake component called CPack is one that can handle packaging a 
distribution for user installation using other generators (pkg, rpm, 
NSIS, etc).  There's no reason to have the development and packaging 
install location be the same and often isn't.

CMake's sandbox install under all other unix platforms (including 
cygwin), defaults to /usr/local.

Besides finding where /usr/local resides as a windows path (which is 
easy),  many commands of cmake can locate libraries or other files 
(similar to autoconf commands), so a full support of cmake under MSYS 
needs to eventually really learn about all of the mingw/msys mountpoints.

 From Bill's pov, this can present some long term headaches.

For cmake to know msys mountpoints, there are now 4 proposed approaches:
    - link against a msys library.  This is Bill's preferred approach.  
This causes the headache of now having 3 different cmake versions on 
windows (cygwin, msys and win32 native).  I'm somewhat opposed to this 
as I think a single cmake should be able to output files for all 
variations under windows unless a proprietary library (read: windows) is 
the issue.  The big benefit is that cmake will not care how msys 
resolves paths now or in the future.
    - parse /etc/fstab.  Potentially could have some issues with some 
mountpoints not listed, it seems.
    - Use the output of "mount".  No problems.
    - Use sh -e "cd path; pwd -W".  No problems, but somewhat slow. 

CMake in general goes to a little bit more trouble than autoconf does to 
avoid path naming, length and win32 issues, albeit it may not always be 
successful with windows paths under a unix-like makefile.

Gonzalo Garramuño

AMD4400 - ASUS48N-E
Kubuntu Edgy

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Mingw-msys mailing list