[cmake-developers] Alternate if() without implicit variable expansion

[Nils Gladitz]

On 09/05/2014 02:50 PM, Brad King wrote:
> On 09/04/2014 11:58 AM, Nils Gladitz wrote:
> - The dashboard submissions that bootstrap got many CMP0054
>    warnings.  Most of them are the same warning repeated due
>    to presence in a macro or loop.  Please update the warning
>    to not warn on the same line more than once.  A set<> of
>    already-emitted warning lines can be kept somewhere.

I'll look into it.

Would it be ok to set the policy for cmcurl to OLD?

I assume that makes it easier to pull changes from upstream than when I 
fix the code to comply with the new policy; also it isn't always clear 
what the intention was with the given conditionals and I am more likely 
to break something.

>
> - I think we can generalize the policy a bit further.  Consider:
>
>     set(x EXISTS)
>     if("${x}" STREQUAL "EXISTS")
>
>    Currently that will get an error because the evaluated
>    variable spells "EXISTS" which is treated as a keyword.
>    The policy could also make if() honor such keywords only
>    when they are unquoted.
>

I'll look into it.

> - The new cmExpandedCommandArgument class interface could
>    be simplified by making it derive from std::string and
>    then just add the boolean as an extra member.

I think composition is cleaner and more future proof in this case 
though; I'd like to keep it unless you insist it should be changed.

> - In the documentation we need to be precise about when
>    the expansion is still allowed.  The cmake-language(7)
>    manual defines unquoted, "quoted", and [[bracket]]
>    arguments as distinct argument types.  We should use the
>    same terminology here.  You can even link back to the
>    manual with cross-reference syntax:
>
>     :ref:`Bracket Argument`
>     :ref:`Quoted Argument`
>     :ref:`Unquoted Argument`

I kept the distinction in cmExpandedCommandArgument at first but then 
generalized it so that bracketed, quoted  and C++ side "0", "1" constant 
arguments would be subsumed. This could be expanded again if there are 
future use cases where they need to be distinguished.

I'll document the current behavior for if().

> Also please extend the test cases for this policy to cover:
>
> - All if() command conditions that do variable-or-string.

Will do.

I was also thinking about setting up an alternative testing 
infrastructure parallel to RunCMake which runs cmake in script mode 
rather than performing configuration/generation.

It would be nice to have something less granular which would allow 
multiple related test cases, expected outputs and exit statuses in a 
single file (which I think could be nicely done with the new bracket 
syntax).

Not for this topic obviously but would this make sense in general?

e.g. something similar to

expect_failure(
[[
   if(
]],
   [[Parse error.  Function missing ending ")".  End of file reached.
]])

> - if() inside a macro() and a function(), covering each
>    combination of policy settings when the macro/function
>    is recorded and when it is invoked.  The policy value
>    should be that when the macro/function was recorded.

Is that behavior command specific?
Isn't it covered by policy testing in general?

Nils