[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