[cmake-developers] Converting cmake_parse_arguments to a builtin command

[Matthew Woehlke]

On 2013-12-06 15:42, Brad King wrote:
> On 12/06/2013 03:11 PM, Matthew Woehlke wrote:
>> On 2013-12-06 14:51, Daniele E. Domenichelli wrote:
>>> 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...
>>
>> FWIW, I was sort-of hoping it would be. If so, CMakeParseArguments.cmake
>> can be left with a simple stub to call the new version.
>>
>> As a bonus, the new version could itself take named arguments instead of
>> positional with a flag whether or not to skip empty (default = keep)
>> with the compatibility wrapper instead specifying to skip, and no policy
>> would be needed (if you want the new behavior, just use parse_arguments).
>
> The C++-implemented command would be able to handle both the existing
> positional or a new proposed keyword-based signature.  The name
> "parse_arguments" is not specific enough about what kind of arguments
> it parses.  By keeping the name as "cmake_parse_arguments" it indicates
> that it parses cmake-language arguments, though another name such as
> "process_cmake_command_arguments" would do that too.

Sure, I can see the argument. I'm not sure I'm entirely sold on 
'cmake_parse_arguments', but 'parse_cmake[_command]_arguments' makes 
perfect sense to me. (IMHO 'parse' makes more sense than 'process'... 
the command doesn't actually do anything with the arguments as might be 
implied with 'process'; just extracts them, which to me is 'parsing'.)

I could go either way on 'cmake' vs. 'cmake_command'... the brevity of 
the former is nice, while the specificity/clarity of the latter is also 
nice. (Well, maybe not; I think I am actually leaning toward the latter 
:-).)

> An advantage of keeping the name is that existing callers get the
> speed-up immediately.  Furthermore there will be less code left in the
> old module to maintain.

I think that is still true if the module just wraps the new function?

> Matthew, would you have time to work on the C++ impl?  I think we could
> start with reproducing the current signature.  Optionally add the policy
> for handling empty arguments.  Then add a proposed keyword-based sig
> that handles empty arguments always.

If someone can sponsor it, maybe? Not for a few days at least, though.

-- 
Matthew