AW: [Mingw-msys] Bison-2.0-MSYS.tar.gz
- Date: Thu, 25 Oct 2007 04:59:30 -0300
- From: Gonzalo Garramuño <ggarra@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-msys] Default install location for CMake
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
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.
AMD4400 - ASUS48N-E
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