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

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Reply via email to