Web lists-archives.com

Re: [Mingw-msys] Re: termcap

On 10/25/07, Gonzalo Garramuño <ggarra@xxxxxxxxxxxxxxxxx> wrote:
> 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.

Right, the question is whether MSYS guys are Windows native guys or Unix guys.

> The MinGW defaults to mingw-make if
> found, if I'm not mistaken, which further avoids path issues.

The MinGW generator doesn't specify what Make you're going to use.  It
does, however, create Makefiles that mingw32-make can use under a
Windows Command Prompt.  Bill could comment more on the differences
between the MinGW and MSYS generators if it's relevant.

> 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.

Assuming that people use both CMake and CPack is assuming too much.
Especially since CPack hasn't been ready for prime time until fairly
recently, if it even is now.  When I was working on the Chicken
Scheme-to-C compiler, we were distributing source code only on all
platforms.  You had to compile for your platform to install.
Additionally, CPack can certainly "lose out" when competing with other
packaging technologies.  Especially on the Linux platform where
Autoconf compatibility is currently more important to the lazy Unix
developers who don't really care about cross-platform stuff.  This is
part of why I'm not working on the Chicken project any longer.  Over
the past year, CPack wasn't at much more than the "future promises"
stage and the Unix guys just went off and did what works now.  People
oohed and aaahed about integration with packagers and Subversion and
my work was sidelined.

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

Right, the question is whether people are meant to install "under
MSYS" or *outside of* MSYS.  A Windows native developer views MSYS as
a throwaway.  Once you've accomplished your build, you're not going to
use MSYS at all.

> For cmake to know msys mountpoints, there are now 4 proposed approaches:
>     - link against a msys library.  This is Bill's preferred approach.

The idea being that if you're plopping stuff into /usr/local, you're
trying to create MSYS native build tools.  i.e. You're not doing
Windows native development at all, you're doing things that will work
*only* within MSYS.

> 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.

I can't remember if CMakeSetup's "Unix Makefiles" generator can
produce something usable under Cygwin.  I've been using CCMake under
Cygwin, which has been the canonical way of doing things.  Trying to
consolidate CMake with respect to Cygwin is outside the scope of the
present discussion.  It's an implementation and licensing issue, not
to mention busywork, as the current approach works fine.  Basically,
the Cygwin folk have their own special CMake package in their archive,
and none of them are telling us they have a problem with that.

Brandon Van Every

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