Hi all.
I hope I don't derail the conversation, but since there's now discussion of
providing a new interface and perhaps behaviour-changing parameters for
cmake_parse_arguments(), I'd like to mention another behaviour switch I
would find useful.
I maintain a CMake framework for a large collection of projects at work,
and this framework provides several functions which (naturally) use
cmake_parse_arguments() internally. My users (and myself when I first saw
it) were quite surprised that repeating the leading keyword for multi-value
parameters overwrites values instead of appending them. What I mean:
function(foo)
cmake_parse_arguments(arg "" "" "MULTI" ${ARGN})
foreach(item IN LISTS arg_MULTI)
message(STATUS "${item}")
endforeach()
endfunction()
foo(MULTI x y MULTI z w)
The above code outputs 'z' and 'w'. I originally expected it to output all
of 'x' 'y' 'z' 'w'. I would certainly welcome an option to switch the
behaviour to the latter one.
Petr
On Wed, Nov 6, 2013 at 9:01 PM, Matthew Woehlke <matthew.woeh...@kitware.com
> wrote:
> 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
>
--
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
