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