Re: [Mingw-msys] Default install location for CMake

[Gonzalo Garramuño <ggarra@xxxxxxxxxxxxxxxxx>]

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:

http://www.cmake.org/pipermail/cmake/2005-November/007510.html
http://www.cmake.org/pipermail/cmake/2005-November/007533.html

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

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:
  cmake -DCMAKE_INSTALL_PREFIX=$PROGRAMFILES
or:
  cpack
Or:
   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 
cygwin/msys distro.
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).


-- 
Gonzalo Garramuño
ggarra@xxxxxxxxxxxxxxxxx

AMD4400 - ASUS48N-E
GeForce7300GT
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
Mingw-msys@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/mingw-msys