Well, since I started this whole fire storm I think I will post a
reply. I was trying to make the case for a possibly "better"
installation location based on running OS X for over 7 years. Some
options are good. The current OS X installer used by CMake is fine.
Bill is correct in the fact that they can not get any more "native"
than that. I was only hoping for the "option" to install somewhere
else than the default of /usr/bin. The power uses who understand the
implications of moving cmake to another installation location will
understand we have to adjust our path. Those who do not understand
path issues probably don't care what is placed where, they just want
their app to work as Bill has stated.
So, as Bill has suggested, allowing for the selection of the
installation location (the default being /usr/bin) would basically
satisfy everyone would be my guess. It would certainly satisfy me.
Sorry for all the noise on this issue but I really thought that it
deserved a bit more discussion.
--
Mike Jackson Senior Research Engineer
Innovative Management & Technology Services
On Dec 22, 2007, at 6:20 PM, Brandon Van Every wrote:
On Dec 22, 2007 4:24 PM, Bill Hoffman <[EMAIL PROTECTED]>
wrote:
I still don't see the reason for the strong resistance to using an
installer program. Many Apple products including Xcode use one.
Clearly a cultural issue. You're running afoul of "Mac native"
culture as opposed to cross-platform development culture. I don't
think platform bigots on any platform are to be taken too seriously.
If they actually need to do cross-platform development, they will use
whatever method actually works in practice. In that world view, you
ship an installer, use it to configure the PATH options, and end the
debate.
That said, newbies may have a "bitch, moan, then accept" period to go
through. The danger is they may instead go through "bitch, moan, then
reject." They may not have sought out CMake, it may have semi-forced
upon them. If they have a choice, i.e. if they're not going to get
fired for rejecting CMake, then they may jolly well reject CMake on
insubstantive grounds. For example, they might be a native MacOS
developer at some company, and the Windows or other cross-platform
group is floating CMake as a pilot project. The company may care
about cross-platform development and CMake, but the individual
employee may not. Enough grousing native MacOS developers might
prevent the use of CMake. They might even prevent any cross-platform
corporate strategy, if they have sufficient lame excuses / ammunition
to force their point of view.
So, I'm saying there's a motive to make CMake "palatable" to a native
MacOS bigot. It's a way of converting such a person into a bona fide
cross-platform developer (who does not care about such trivia
anymore). Which in turn is a way of converting organizations.
Particularly in larger organizations, there are many teams running
around, competing with each other for the focus of the company. The
ascendancy or decline of any given team may depend upon touchy feely
issues, not necessarily core technical merit.
In that world view, you'd add "first run invokes path configuration"
because it gives native MacOS bigots a warm squishy feeling. Then
they're singing the praises of CMake instead of bitching and moaning
about it.
The first invocation doesn't have to be through a GUI either. ITon
the command line, either from CMake's installation directory or from
an absolute path.
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
