[cmake-developers] fphsa capitalization

[Eric Noulard]

2010/8/14 Alexander Neundorf <neundorf at kde.org>:
> On Friday 13 August 2010, you wrote:
>> On 08/13/2010 03:32 PM, Alexander Neundorf wrote:
>> > Which means that if we would switch to Exact case, there would be a
>> > mixture of ExactCase and UPPERCASE for years
>>
>> In that case you should never be writing any CMake commands in lower
>> case because at one time 100% of CMake code used upper case commands.
>> Now there is a mixture but most people prefer lower case commands.

But all of those practices are compatible :-)

>>
>> I fully understand and appreciate your "existing practice" argument
>> but I weight it differently.  The longer we wait to provide ExactCase
>> variables the more code there will be that uses UPPERCASE.
>
> One last thing: also all the variables and properties coming from cmake (like
> CMAKE_SOURCE_DIR, CMAKE_SYSTEM_NAME, BUILD_WITH_INSTALL_RPATH etc.) are also
> all UPPERCASE.

Ok guys,

We have **MANY** or **Many** or **many** good reasons to prefer
UPPERCASE vs ExactCase vs UPPERCASE vs ExactCase...

To summarize:

     1) UPPERCASE (for variable names) is a statistically the more
used practice:
         CMake itself (at least all CMAKE_xx and CPACK_xx), the FindXXX modules,
         [it seems to be the case for most MACRO name too -- my
experience though]

     2) ExactCase is more consistent for a fair amount of FindXXXX filenames
         and habits (lower case CMake commands).
         Some people (I would say many but there is not so many
         people on this thread :-) probably **instinctively** think
         ExactCase and the argument that find_package(WhatEver)
         currently **NEED** to be exact case is off course right.

     3) CMake currently accept either lower_case or UPPER_CASE
         or MixEd_CaSe command
         (advertised in the tutorial:
          http://www.cmake.org/cmake/help/cmake_tutorial.html)
         but the usage seems to be either lower_case or UPPER_CASE
         but not really Mixed_Case (but it works).

Borrowing the idea from 3) I would say that it does not seem "reasonable"
to **enforce** either UPPERCASE or ExactCase. May be we can propose
some compatible change for some time (may be forever but the future will tell)?

My proposal is:

    1) State clearly that ExactCase is preferred to UPPERCASE

    2) Change GET/SET behaviour:
           2.a) set(ExactCase 1) but...
                 WARN loud if set(EXACTCASE 1) comes after a set(ExactCase 1)
                 or if set(ExactCase 1) comes after set(EXACTCASE 1)
                 more generally if strcasecmp(first,second) is 0.

           2.b) ${WhAtEverCASE} (which is a get) should give the value
                 of either:
                        1) first the variable with exact case (today's behavior)
                        2) the variable with case insensitive match
                            **if there is only one**

   3) Authorize find_package(EXACTCASE) to be be successful
       for a FindExactCase.cmake package but WARN loud
       about this fact.

   4) Set up 2 new cmake policies which may be set to new

          CMPxxx in order to enforce "strict" ExactCase behavior
                       (or issue a WARNING if you get(WhAtEverCASE)
                        instead of get(WhatEverCase).

          CMPyyy in order to disable the whatever case "new behavior"

That proposal has drawbacks and advantages:

     * Drawbacks

           - there is some coding/testing time but even if I'm not
             familiar with this part of CMake code I would say that
             modifications should mainly appear in cmDefinitions
             (and off course cmPolicies.cxx)

           - The processing of getting/setting vars will
             be less efficient because of case insensitive search
             (but an extra case insensitive map may be added
              to lessen this problem while requiring more memory)

     * Advantage

           - We get full backward compatibility whatever the CaSe
             is used. I may imagine some pathological failure because
             of the whatever case default new behavior.
             If you have some doubt set CMPyyy to OLD.

           - 2.a) and 3) Warning may help to track issues
             even with the current behavior

           - FindExactCase may set ExactCase_FOUND
             and let the user use
             if (EXACTCASE_FOUND) without **any problem**
             unless CMPxxx is set to NEW and you get a WARNING or
             a failure.

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?

Your opinion ?
(including technical remark showing me that I totally ignore
 the CMake internals and that my proposal would be nightmare to
 implement and maintain)

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WhatCASE.cmake
Type: text/x-cmake
Size: 587 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20100814/704a26ec/attachment-0002.bin>