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