[cmake-developers] Converting cmake_parse_arguments to a builtin command

[Daniele E. Domenichelli]

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