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