On 2013-11-06 13:57, Brad King wrote:
On 11/06/2013 01:32 PM, Alexander Neundorf wrote:
Adding proper named argument handling to cmake_parse_arguments() itself is
somewhat complicated since it can't make use of cmake_parse_arguments() ;-)
Since the need for this is so common, perhaps we should provide a
C++-implemented command to do it, e.g. cmake_command_options().
We would need to carefully design the interface here first of course.
FWIW, I prefer the name [cmake_]parse_arguments :-).
Is there not already a C++ implementation something like this? (Or else
how do the existing C++ commands do argument parsing?) If it is C++, I
guess it would be possible for it to not have the limitation of being
unable to parse its own arguments? (Actually, in either case, it seems
that the implementation should be able to have all the 'real work' in a
helper that is called once to parse arguments to the command itself,
then again to parse the arguments the user wants to parse.)
In any case, it would be nice if we could reimplement
cmake_parse_arguments so that it has the same signature but the
implementation would newly just wrap the new C++ version.
What if we had something like:
parse_arguments(
PREFIX "_"
FLAG_OPTIONS ...
VALUE_OPTIONS ...
LIST_OPTIONS ...
ARGS ...)
...where everything after ARGS is no longer considered an argument to
parse_arguments itself. Also, 'parse_arguments(... IN LISTS ...)'
(instead of using 'ARGS'), taking names of list variables containing
arguments to be parsed (similar to 'IN LISTS' of foreach).
{FLAG,VALUE,LIST}_OPTIONS would accept one or more strings containing
names of argument keywords, subject to recursive list expansion (should
be safe - keywords should not contain ';' - and avoids breakage if
option name lists are given in quoted variable expansions, which could
easily happen by forgetting to remove quotes when porting to the new
signature).
...and then of course cmake_parse_arguments can readily accept other
options to modify its behavior e.g. KEEP_EMPTY (and/or SKIP_EMPTY if
keeping becomes - or may be, depending on policy - the default).
--
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
