On Thu, Jan 20, 2011 at 1:11 PM, Clinton Stimpson <clin...@elemtech.com> wrote: > On Thursday, January 20, 2011 09:36:13 am Eric Noulard wrote: >> 2011/1/20 David Cole <david.c...@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 _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
