On 2010-08-14 18:59+0200 Alexander Neundorf wrote:
On Saturday 14 August 2010, you wrote:
...
find_package command, it makes a lot of sense to use that same
exact-case name as a prefix for the variables set by that find module.
Or in other words: I don't feel like going through the 67 find-modules in
kdelibs and fixing them to provide also Exact case....
I agree, hand-editing the KDE-specific find modules as well as the
official CMake ones would be painful (and subject to errors), but
would such hand-editing really be necessary? Surely, a script could be
written to search and replace variables in find modules that don't
follow the naming convention that is eventually decided while
implementing additional set commands to preserve the old variables for
backwards compatibility.
What is the benefit we gain from using ExactCase compared to UPPERCASE ?
Consistency with the name used by find_package, see my quoted comment
above.
For me that is a "would-be-nice" benefit rather than an absolutely
compelling one so I think the conversion to exact case prefixes is
justified only if there are technical measures (including writing
conversion scripts and also those Eric was talking about) that would
make the conversion process relatively painless. So I am only leaning
toward the exact case naming convention and don't really feel that
strongly about it.
In sum, I don't feel too strongly either way about which naming
convention to use, but I do feel strongly that CMake needs a solution
to the current lack of naming convention. Thus, the important thing
from my perspective is for the CMake developers to come to consensus
(taking all technical measures into account which will
reduce/eliminate the conversion pain) on which naming convention to
use so that implementation of that convention can start.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
