[cmake-developers] fphsa capitalization

[Alan W. Irwin]

On 2010-08-14 16:25+0200 Eric Noulard wrote:

> I know this may seems overkill, because we are only speaking about
> ExactCase vs UPPERCASE, but if we take the backward compatibilty
> seriously and want to progress towards to ExactCMake, may be it's
> a "possible idea".
>
> Now I think I just unveil myself a CMake pandora box, the
> "whatever case" getter I propose is not too far away from the
> MACRO(WhatEvERcase) or FUNCTION(WHATeverCase) behavior.
> I let you run the attached cmake script and tell me if you knew
> this "flexible" CMake command naming was true for MACRO and
> FUNCTION too ? This is genuine consistent but why doing this
> on macro and not on vars?

As a CMake-based build-system implementer for various software
packages, I was well aware of and do like the convenience of
case-insensitive use of commands, macros, and functions.  However,
variables are a different story and _in general_ there you want to
maximize the possibilities for the largest possible namespace so case
insensitivity would be a bad idea for variables _in general_. 
However, for the specific case of the variables set by find modules,
the present mess is unacceptable, and CMake should move to an enforced
consistent naming convention as soon as possible.

I will let others more competent than me in CMake internals comment on
the technical merits of Eric's proposals, but I think the idea of
removing a lot of the pain of converting to a consistent naming
convention for the variables set by find modules using technical means
is a good one. Assuming Eric's or similar proposals are implemented to
remove that conversion pain, I agree with Brad that since we already
must use exact case for referring to the find module name with the
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.
My hope is that with the conversion pain removed, Alex would be
willing to go along with the exact case naming convention so that
solving the current naming convention mess is not delayed too much
longer.

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
__________________________