Re: [Mingw-msys] Re: Earnie's views on adding packages dependent on MSYS
- Date: Thu, 25 Oct 2007 12:39:23 -0300
- From: Gonzalo Garramuño <ggarra@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-msys] Default install location for CMake
Brandon Van Every wrote:
> Right, the question is whether MSYS guys are Windows native guys or Unix guys.
And why do you care? You already have at least one person (me) telling
you they do both.
And actually, there's another one. *Yourself* back in 2005:
I googled the mailing lists as you suggested and so far that's the best
I could find about this issue.
CMake already caters to both camps by offering two different generators.
You like native windows development? MinGW generator it is. You then
may have to use a different MinGW make so that "C:" is not taken as a
rule. And you *may* run into the OS limitation on paths and the
like.... it *is* the nature of the platform you are developing for (and
cmake really does go to great lengths to try to avoid the problems, btw).
And with cmake you can also choose an NMake generator instead. Nmake is
Either way, as I pointed out, CMake is intended for *DEVELOPMENT*, not
user distribution. As such, anyone that tries to compile the source
code you distribute should be either:
a) A developer or someone that wants to learn from the source.
b) Someone that does not trust *you* to give *them* a binary.
c) Someone that wants to verify the tool is really open source.
Whether it is a) or b) or c), they probably DON'T want to install the
software globally without first giving it a test-run in an isolated
place. /usr/local is just as good as any, but it is consistent to the
location used by MSYS for autotools.
> Assuming that people use both CMake and CPack is assuming too much.
And who assumes that? I just said that if you want to do user
distribution, there's tools specific to do that, even in cmake.
If you don't like CPack, I strongly recommend InstallJammer,
particularly once 1.3 ships with OSX support, which is its main
Achilles' heel right now.
If you need mac, win, and linux support *right now* -- InnoSetup. Or
some commercial solution.
> Additionally, CPack can certainly "lose out" when competing with other
> packaging technologies.
Well, then don't use it or try to develop it further.
I use InstallJammer with cmake and I'm *very* happy with the mix.
InstallJammer is a very well developed tool and does not even require
you to do any scripting. Albeit I'm pretty techie, I use it straight
from the GUI to do all my installs.
> 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.
And why do you make that assumption? With /usr/local you can *still* do
native development. You test the stuff works in /usr/local first and
only *then* use:
cp myfiles* somewhereelse
and package the stuff with some other nice install GUI for non-techie users.
> Trying to
> consolidate CMake with respect to Cygwin is outside the scope of the
> present discussion.
Partially correct. However it is also partially true that the change I
propose for MSYS could consolidate how cmake deals with *BOTH* Cygwin
and MSYS, leading to less code to maintain and to no longer need to link
it against (some) special libraries. You would then leave the task of
linking against a special lib to a small exe that comes with the
The benefit is obvious. A *single* cmake could then target EVERY
windows developer or workflow and be *always* up to date to the latest
msys/cygwin I have installed. I find that VERY appealing.
The only potential headache down the line with win64 could be symlinks
(and only maybe).
P.S. I apologize for this having been brought to MSYS, as I'm not
entirely sure this thread belongs here, other than learning how to
better integrate MSYS (which we did, I think).
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