Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
On 05/11/13 20:51, Alexander Neundorf wrote:
I don't know if this is to be considered a change of behaviour though,
but I'd rather consider it a bug, and I would like to see it fixed in
the next bugfix release... what do you think?
cmake_parse_arguments() is used in quite a few places in the meantime, so I
don't really feel good about changing its behaviour in general.
Maybe an option for the macro what it should do with empty values ?
Is there any of the other place where cmake_parse_arguments() has to
deal with with empty arguments? I believe that someone would have
complained about that. From what I've seen, modules that are supposed to
deal with empty arguments (like ExternalProject that can have arguments
like INSTALL_COMMAND ) do not use CMakeParseArguments...
I don't think that anyone would use something like
SINGLE VALUE
to assign VALUE to the SINGLE option...
Also something like
SINGLE ${EMPTY_VARIABLE} NEXT_ARG
would assign to FOO_SINGLE the value NEXT_ARG
and that is very likely to be an unintended behaviour.
Perhaps someone could use something like
MULTI ${V1} ${EMPTY_VARIABLE} ${V2}
and expect to get a list containing only V1 and V2. Nonetheless if he is
using foreach(arg ${list}), the behaviour won't change because empty
list elements are skipped. if instead he is using foreach(arg IN LIST
list), he is probably expecting to receive empty arguments, since the
documentation clearly states so.
Adding an option in the macro arguments would be a bit of a
non-compatible change, since the name of the option could no longer be
used as one of the OPTION/SINGLE/MULTI value names.
Also using a global property is not an option, because that would change
the behaviour globally, and if some module is expecting the current
behaviour it will still fail.
Cheers,
Daniele
--
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
[cmake-developers] [CMake 0014548]: CMAKE_MAKE_PROGRAM, not CMAKE_BUILD_TOOL used for verification of JOM during configure step
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14548 == Reported By:Steve Wolak Assigned To: == Project:CMake Issue ID: 14548 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-06 11:05 EST Last Modified: 2013-11-06 11:05 EST == Summary:CMAKE_MAKE_PROGRAM, not CMAKE_BUILD_TOOL used for verification of JOM during configure step Description: When attempting to configure for a JOM build system, JOM should be in the path. I find this acceptable, but also wanted a way for the users of our system to be able to specify where to find the JOM executable in another way. After looking at the CMake documentation I found CMAKE_MAKE_PROGRAM, which says: See CMAKE_BUILD_TOOL. This variable is around for backwards compatibility, see CMAKE_BUILD_TOOL. I allow the user to set an environment variable that points to the JOM executable. I then use this environment variable during generation of the JOM makefiles in the following way: cmake -DCMAKE_TOOLCHAIN_FILE=some value -DCMAKE_BUILD_TOOL=User provided information -G NMake Makefiles JOM. I found this did not work for the configure step as CMake would fail to compile the test programs because it couldn't locate JOM. Interesting, I thought. The cache certainly had CMAKE_BUILD_TOOL set as I expected it to. I then noticed that CMAKE_MAKE_PROGRAM was still set to just jom. Ah!. I modified my CMake command to be: cmake -DCMAKE_TOOLCHAIN_FILE=some value -DCMAKE_MAKE_PROGRAM=User provided information -DCMAKE_BUILD_TOOL=User provided information -G NMake Makefiles JOM . And the configure step worked correctly. I believe that CMAKE_MAKE_PROGRAM should be set to CMAKE_BUILD_TOOL in the cache, or perhaps the documentation needs to be updated to state that it's used for the JOM generator, or maybe the step that checks that the compiler works needs to be updated to use CMAKE_BUILD_TOOL instead of CMAKE_MAKE_PROGRAM when generating JOM files. Steps to Reproduce: Leave JOM out of your path, but be sure to add the necessary information for Visual Studio (i.e. run vcvarsall.bat or similar script). Attempt to run cmake -DCMAKE_TOOLCHAIN_FILE=some value -DCMAKE_BUILD_TOOL=Path to JOM, including executable -G NMake Makefiles JOM . Configure should fail. Clear the cache file then run: cmake -DCMAKE_TOOLCHAIN_FILE=some value -DCMAKE_MAKE_PROGRAM=Path to JOM, including executable -DCMAKE_BUILD_TOOL=Path to JOM, including executable -G NMake Makefiles JOM . Configure works Additional Information: I would like to be able to pass the build tool to CMake at configure, but some clarification is needed on the correct way to do that. == Issue History Date ModifiedUsername FieldChange == 2013-11-06 11:05 Steve WolakNew Issue == -- 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
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
On Wednesday 06 November 2013, Daniele E. Domenichelli wrote:
On 05/11/13 20:51, Alexander Neundorf wrote:
I don't know if this is to be considered a change of behaviour though,
but I'd rather consider it a bug, and I would like to see it fixed in
the next bugfix release... what do you think?
cmake_parse_arguments() is used in quite a few places in the meantime, so
I don't really feel good about changing its behaviour in general.
Maybe an option for the macro what it should do with empty values ?
Is there any of the other place where cmake_parse_arguments() has to
deal with with empty arguments?
We cannot know what users are doing with it.
I believe that someone would have
complained about that. From what I've seen, modules that are supposed to
deal with empty arguments (like ExternalProject that can have arguments
like INSTALL_COMMAND ) do not use CMakeParseArguments...
I don't think that anyone would use something like
SINGLE VALUE
to assign VALUE to the SINGLE option...
Also something like
SINGLE ${EMPTY_VARIABLE} NEXT_ARG
would assign to FOO_SINGLE the value NEXT_ARG
and that is very likely to be an unintended behaviour.
Perhaps someone could use something like
MULTI ${V1} ${EMPTY_VARIABLE} ${V2}
and expect to get a list containing only V1 and V2. Nonetheless if he is
using foreach(arg ${list}), the behaviour won't change because empty
list elements are skipped. if instead he is using foreach(arg IN LIST
list), he is probably expecting to receive empty arguments, since the
documentation clearly states so.
Adding an option in the macro arguments would be a bit of a
non-compatible change, since the name of the option could no longer be
used as one of the OPTION/SINGLE/MULTI value names.
This is all correct.
It seems unlikely that changing this will actually break something.
Adding an option like DONT_SKIP_EMPTY_ARGUMENTS, e.g at the second argument
position, means that this keyword cannot be used as an option name by users
anymore. By making the keyword longer or more detailled, this becomes less
likely. E.g. I'd assume nobody is using CMAKE_DONT_SKIP_EMPTY_ARGUMENTS.
Adding proper named argument handling to cmake_parse_arguments() itself is
somewhat complicated since it can't make use of cmake_parse_arguments() ;-)
The macro could check ${CMAKE_MINIMUM_REQUIRED_VERSION} whether 2.8.13/3.0.0
is required, and switch behaviour based on that. Or via a policy. This would
be the normal wy to handle such a change.
I'm not sure whether this wouldn't be a bit much for a change which most
likely doesn't break anything anyway.
But... I've had my share of changes which seemed to be safe, and then somebody
came along with a setup which was broken by this change nevertheless.
So, I'll have a slightly bad feeling if you commit it without additional
checks. Probably it will be ok.
If you commit it with a policy, everything should be fine.
Alex
--
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
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
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. -Brad -- 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
Well I've tried to make the problem as clear as possible but somehow it seems it still wasn't clear enough. In my opinion the solution which was proposed by Mathew was also pretty clear - also not absolutly complete as he stated himself. How should we proceed? I think Mathew understood what's my problem. On Wed, Nov 6, 2013 at 4:18 AM, David Cole dlrd...@aol.com wrote: On Nov 5, 2013, at 6:40 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 17:40, David Cole wrote: I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. 1. I can modify my shortcut / .desktop file (which I previously stated as a use case for the feature). 2. I can launch cmake-gui from the run / launcher dialog. In both cases, I'm not using a (full) CLI, but I can still pass command line arguments. (The latter is admittedly a little CLI-like, but its working directory is still poorly defined and probably you are not specifying a build directory in that case.) Ok, I guess I should know better than to use the word IMPOSSIBLE... Although I would call both of those (perhaps sideways) CLI usage. I think the feature should be well-defined and easy to explain before it's implemented. I will defer to the wisdom of the crowd on this, (i.e. I've said my piece and now I'll be quiet) but if it can't be explained in a short paragraph of text, I still maintain that it's overly complicated. D -- 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
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 11/06/2013 02:55 PM, physhh . wrote: How should we proceed? I think Mathew understood what's my problem. This thread has covered use cases in which it makes sense to apply (or not apply) command-line parameters in cmake-gui for various cases. No one automatic behavior is going to satisfy everyone. Nobody picked up on Matthew's suggestion here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8553/focus=8553 which was: On 11/05/2013 02:56 PM, Matthew Woehlke wrote: What about having an option (e.g. a combo box) when to apply command line options? - At startup (only initial / specified on command line build directory) - New projects (when no CMakeCache.txt exists yet, but also at startup) - Unconfigured projects (per my original proposal) - Always (i.e. when selecting a different build directory) The default could be 'new projects' if no build directory is specified on the command line (probably you are giving common rather than project specific options in this case), otherwise 'at startup' (more chance options are project specific). Another approach is to have an Apply Command Line Parameters button appear whenever -Dvar=value parameters were passed. This will allow users to put their command-line options into effect at any time without changing any settings. The button should not pay attention to command-line options that set the source/build trees. If that is not sufficient then Matthew's proposed combo box can be used to select when command-line parameters are applied automatically. -Brad -- 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
+1 I like the idea of the [Apply Command Line Parameters button appear whenever -Dvar=value parameters were passed.] Would also be nice if parameter like -G ... could also be considered for the first configuration. Within some of our project, I envision user downloading a bat script named BuildMyProjectWithVS2008.bat that would pass all the expected option to cmake-gui. Aware the same could be done directly with cmake or ccmake .. but visual studio user often expects UI with buttons On Wed, Nov 6, 2013 at 3:33 PM, Brad King brad.k...@kitware.com wrote: On 11/06/2013 02:55 PM, physhh . wrote: How should we proceed? I think Mathew understood what's my problem. This thread has covered use cases in which it makes sense to apply (or not apply) command-line parameters in cmake-gui for various cases. No one automatic behavior is going to satisfy everyone. Nobody picked up on Matthew's suggestion here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8553/focus=8553 which was: On 11/05/2013 02:56 PM, Matthew Woehlke wrote: What about having an option (e.g. a combo box) when to apply command line options? - At startup (only initial / specified on command line build directory) - New projects (when no CMakeCache.txt exists yet, but also at startup) - Unconfigured projects (per my original proposal) - Always (i.e. when selecting a different build directory) The default could be 'new projects' if no build directory is specified on the command line (probably you are giving common rather than project specific options in this case), otherwise 'at startup' (more chance options are project specific). Another approach is to have an Apply Command Line Parameters button appear whenever -Dvar=value parameters were passed. This will allow users to put their command-line options into effect at any time without changing any settings. The button should not pay attention to command-line options that set the source/build trees. If that is not sufficient then Matthew's proposed combo box can be used to select when command-line parameters are applied automatically. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 -- 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
Re: [cmake-developers] Capturing VCS tool output?
On 11/06/2013 03:45 PM, Pedro Navarro wrote: I'm debugging an issue with P4 updates and would like to get the output of all the p4 commands I issue, like the ones to get the old and new revisions. I'm interested in both the stdout and stderr output, which I'm capturing with OutputLoggers. The Testing/Temporary/LastUpdate*.log files should have all the vcs tool interaction history. -Brad -- 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
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
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
