[CMake] Re: cmake 2.4.8 RC 4

Bill Hoffman bill.hoffman at kitware.com
Fri Dec 21 19:48:47 EST 2007


Rodolfo Schulz de Lima wrote:
>>  In my NOT so humble opinion, this is a REALLY bad idea and here is  why.
> 
> I second this. In linux who deals with /usr is the package manager (apt, 
> portage etc). If I deliberately install something there, the package 
> manager won't know about it and maybe something might be overwriten in 
> the future. /usr/local exists for a reason, and in a well configured 
> system, /usr/local/bin comes BEFORE /usr/bin in PATH, I think it's not 
> cmake's fault when something gets installed and cannot be run, it's users.
> 

OK, what do you mean a well configured system?  Someone buys a Mac, the 
install Xcode, and well, they are done.  The system is as configured as 
it gets.  I don't want to get into the business of changing PATHS on OS 
X.  It is not like windows where there is a single registry entry that 
will get all the possible shells.  On OS X, like any other UNIX, there 
is .bashrc, .tcshrc, .*rc or any other number of places the PATH can be 
set.   Mac's are single user machines, that are not usually administered 
by a sys-admin like other UNIX machines.  I really can't see apple 
destroying the cmake install in /usr/bin.   Is there any documentation 
from Apple saying not to install 3rd party software into /usr/bin?


Looks like darwin Ports does not like /usr/local:
http://trac.macosforge.org/projects/macports/wiki/FAQ
Although, looking at the darwin ports docs, they require the user to 
change the path.   CMake is a single project not a group of tools like 
Darwin port or fink.  Although CMake is available from fink, and I am 
sure they put it somewhere else.  But for the one from Kitware, it 
should just work on a stock system after the install.

-Bill


More information about the CMake mailing list