[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 )

[Eric Noulard]

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 :-]


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org