[cmake-developers] On Mac OS X, the CMake .app filename should not contain the version number ( http://public.kitware.com/Bug/view.php?id=11693#c24958 )

Marcus D. Hanwell marcus.hanwell at kitware.com
Thu Jan 20 13:39:20 EST 2011


On Thu, Jan 20, 2011 at 1:11 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
> On Thursday, January 20, 2011 09:36:13 am Eric Noulard wrote:
>> 2011/1/20 David Cole <david.cole at kitware.com>:
>> > Moving to the CMake developer's list, as requested by this bug comment:
>> > http://public.kitware.com/Bug/view.php?id=11693#c24958
>> >
>> > Comments or thoughts on the topic are welcome...
>> >
>> > Please reply here with any further discussion before adding more info
>> > to the bug report. Once a consensus is reached here, we'll update the
>> > bug again.
>>
>> I'm not a Mac user and I'm a poor Windows user :-]
>>
>> Now on linux (or other unices) I was puzzled by the /usr/share/cmake-2.8
>> thing in fact the vast majority unix software don't come with such version
>> mangling. FHS doesn't seems to include recommandation in this area:
>> http://www.pathname.com/fhs/.
>>
>> Sometimes the version mangling appears when a major update (python2 -->
>> python3) arrives and one needs to have both versions installed for
>> compatibility reason. In this case, most of the time, the up-to-date
>> version is unnumbered and the old compatibility one is renamed with
>> version mangling.
>> In fact before the big old->new update thing the new version may be
>> mangled for a
>> while waiting for wider acceptance (Python case).
>>
>> Some libs do always have name mangling because the version is really part
>> of their name., e.g. glib-2.0.
>>
>> Then update-alternative (Debian, Fedora, ?others?) may be used
>> to create appropriate links:
>> http://www.debian-administration.org/articles/91
>>
>> So I vote for no version mangling.
>> Or may be an option (default to OFF==no mangling) in order to ease the
>> mangling of cmake-2.8
>> when cmake 3.0 will be out :-]
>
> I also vote for no version number, but allow the user to change it if they
> want.
> It seems that would give the general user a more clear upgrade path.

I vote for no version number. It is pretty irritating having to
recreate my build trees when I upgrade CMake, and it does not seem to
fit into the normal pattern used on the Mac.

I also noticed the /usr/share/cmake-2.8, and without a
/usr/bin/cmake-2.8 I am not sure it makes sense on Linux distros - two
CMake's could not coexist in the same prefix as the main binary would
collide.

Marcus



More information about the cmake-developers mailing list