On 12/06/2013 02:51 PM, Daniele E. Domenichelli wrote: > 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...
Well, almost empty :) > 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 I see no reason to distribute code in the CMake 3.0 version of the module that is meant to work with versions prior to 3.0. It will never be tested or executed while running that version of CMake. It would be an untested fork even though it appears upstream. If you're going to use it with CMake 2.8.7 you will need a copy with your project anyway. There is no reason you can't take your current version of the module from this topic and put it in your project with no change to CMake upstream. > 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... I'll respond to this part on top of Matthew's response to it. > 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. Ah, I was confused because ExternalProject-independent-step-targets merges CMakeParseArguments_EmptyArgs. I see it does so only for a conflict resolution. I can resolve that as described below. >> 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, If you are not comfortable trying this there is no requirement to do so. Others have expressed interested in this thread and may be able to volunteer. Based on the preceding discussion I do not think we will be changing the upstream module until the C++ implementation is done. Therefore I will revert the CMakeParseArguments_EmptyArgs topic (which will also help in separating ExternalProject-independent-step-targets from it). See my follow-up post in response to Matthew for further discussion of a C++ implementation. Thanks, -Brad -- 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