On 05/12/13 14:56, Brad King wrote: > Without a policy project authors will not be warned about the change in > behavior that would be caused by bumping cmake_minimum_required(VERSION).
Ok, let's assume that we add a C++ implementation with a CMPXXXX policy that does * OLD policy = SKIP_EMPTY * NEW policy = KEEP_EMPTY If CMAKE_MINIMUM_REQUIRED_VERSION < 3.0.0 and CMAKE_VERSION >= 3.0.0, the author will receive a warning about the policy and that the OLD policy is being used. If CMAKE_MINIMUM_REQUIRED_VERSION >= 3.0.0, the NEW policy will be used, but the author should also be warned that he should no longer include the CMakeParseArguments.cmake file, since it will be deprecated and might disappear in the future. I'm not sure if from C++ you can check that, so an "empty cmake file" won't work... If CMAKE_MINIMUM_REQUIRED_VERSION < 3.0.0 and CMAKE_VERSION < 3.0.0, it means that the module was "backported", the OLD policy should be used and no warning issued. So, what about something like this: --- ### Documentation ### ### Copyright statement ### if(NOT CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 3.0.0) message(AUTHOR_WARNING "cmake_parse_arguments is now a builtin function, the CMakeParseArguments is deprecated and could be removed in the future, therefore it should not be included") # Use C++ implementation return() endif() if(COMMAND cmake_parse_arguments) # If CMAKE_VERSION >= 3 will use the C++ implementation, and # therefore will use the policy and when used will print a warning # about the policy. # If CMAKE_VERSION < 3 this file was already included and will avoid # including several times this file. return() endif() # The implementation is left for backwards compatibility, but might # be removed in the future. ### CMake implementation for CMake < 3.0.0 simplified to use the ### ### OLD policy only (SKIP_EMPTY), but that accepts the ### ### CMAKE_PARSE_ARGUMENTS_KEEP_EMPTY argument and ignores the ### ### CMAKE_PARSE_ARGUMENTS_SKIP_EMPTY one ### --- Does this sound reasonable? Sorry if I stress on keeping the CMake implementation, but I need a solution that could be backported at least to CMake 2.8.7 (that's the best I was able to achieve, we depended on CMake 2.4 a few months ago in order to support very old systems, and for sure I won't be able to change the dependency on CMake 3.0.0 any time soon), and I hate the idea of "forking" and maintaining my own patched version of the CMakeParseArguments module... Are you sure you don't want the command to be renamed to "parse_arguments"? The only commands containing "cmake" looks strictly related to "cmake", and the arguments parsing does not look that much related... > Currently I do not plan to merge the CMakeParseArguments_EmptyArgs topic or > any topics that depend on it (like ExternalProject-independent-step-targets) > to master. Please note that ExternalProject does not use CMakeParseArguments and the ExternalProject-independent-step-targets topic does not depend on this patch, so I don't see a reason for blocking it on this topic. Actually ExternalProject, like several other modules, would probably benefit on using the C++ implementation instead of having their own parsing, or using the cmake implementation, but that's for a following patch. > I'm convinced that the cmake_parse_arguments command should be > converted to C++, taught to handle empty arguments, and handle compatibility > with a policy. Daniele, will you be able to work on this? I will try, but I'll have to do it in my free time, and I don't know how long it will take, because I'm not very confident with CMake "C++" code, because my time very limited at the moment, and because I have several other patches that I want to work on. If anyone else is in a hurry to have this, and wants to take it, feel free... Cheers, Daniele -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers