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

Brad King brad.king at kitware.com
Fri Sep 5 09:31:51 EDT 2014


On 09/05/2014 09:19 AM, Nils Gladitz wrote:
> Would it be ok to set the policy for cmcurl to OLD?

No, but the code could be fixed to not trigger the warning.
See similar changes here:

 Check*: Allow result variables to contain regex special characters
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f2fcce4

Alternatively, just let the warnings go for now so we can see how
they look.  Then we can fix the code in a follow-up change.

> 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.

That's fine.  I'm just talking about the documentation.  Right now
it says "quoted" arguments do not expand in the NEW behavior.  It
should say something more like "only unquoted arguments expand"
since both "quoted" and [[bracket]] arguments are left alone now.

> 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.

You can use "run_cmake_command" to run arbitrary cmake command-line
signatures and still use the rest of the infrastructure.

> 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?

Yes.  The existing RunCMake infrastructure could be extended with
more commands that take the expected pieces directly as arguments.
Then the current infrastructure could be ported to use it after
reading info from the files.

>> - 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?

The policy scope is general behavior, but we need to know that
the forwarding of arguments into commands when replayed from
macro/function works correctly to implement this policy.

Thanks,
-Brad




More information about the cmake-developers mailing list