Re: [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 )
On 20 January 2011 15:52, David Cole david.c...@kitware.com wrote: 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... I'd agree, OSX applications almost never have the version number in the filename. In addition, other CMake things that aren't particularly native: - Using bin/ directories inside Program Files on Windows is a bit weird - I think that CMake shouldn't use version numbers in the Start Menu/folder/executable name on Windows -- Mike McQuaid http://mikemcquaid.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [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 )
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 :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [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 )
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
