[CMake] Mac installation and cultural issues

[Mike Jackson]

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 <bill.hoffman at kitware.com>  
> 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
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake