[cmake-developers] [CMake 0014546]: CACHE variables persist through reruns
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14546 == Reported By:Alp Toker Assigned To: == Project:CMake Issue ID: 14546 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-06 00:33 EST Last Modified: 2013-11-06 00:33 EST == Summary:CACHE variables persist through reruns Description: Hello, We're using CMake in the LLVM/clang Open Source project and noticed that CACHE variables are getting persisted after regenerating makefiles (reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-October/032957.html) This means that upstream SVN changes to any CACHE variable (such as the binary version number, default bug report URL etc.) don't take effect on developers systems. The most visible result of this is that, when the project makes a new release, existing builds continue to use the old version number taken from the cache. This happens with all other CACHE variables too. Steps to Reproduce: Configure a project that has the following CACHE variable in CMakeLists.txt: set(BUG_REPORT_URL "http://llvm.org/bugstypo/"; CACHE STRING "Default URL where bug reports are to be submitted.") Then build the project. Then modify the URL in CMakeLists.txt, changing it from "http://llvm.org/bugstypo/"; to "http://llvm.org/bugs/"; Then rebuild the project. Problem: BUG_REPORT_URL is still "http://llvm.org/bugstypo/"; Expected result: BUG_REPORT_URL should have been updated to "http://llvm.org/bugs/"; The issue has been observed with the Makefile and Ninja generator, and presumably all other generators are affected. Additional Information: I've investigated and this seems to be a bug in cmMakefile::AddCacheDefinition(), which is caching the default value for the variable even when the user hasn't overridden it on the commandline or in the CMake GUI. I'm working on a patch that teaches CMake to differentiate between the declaration, definition and default value of a CACHE variable. An additional benefit of this approach is that it adds a "Reset to default" option for CACHE variables in the CMake GUI. There should otherwise be no change in behaviour other than resolving the problem as described. Specifically, if the user defines the variable explicitly, the user definition will continue persist same as before. I'll upload the patch shortly. Please let me know if you're already aware of / working on an alternative solution to this issue. == Issue History Date ModifiedUsername FieldChange == 2013-11-06 00:33 Alp Toker New 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] [CMake] Forwarding parameters to cmake through cmake-gui
> On Nov 5, 2013, at 6:40 PM, Matthew Woehlke > 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) 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. Therefore, when discussing how command line parameters ought to behave, you do not have to consider the non-CLI use case. (Other than, obviously, not requiring any changes to the non-CLI use case to accommodate new command line features...) 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On Tuesday 05 November 2013, Matthew Woehlke wrote: > On 2013-11-05 14:36, Alexander Neundorf wrote: > > I tried the following a few times in the past and noticed everytime that > > it does not work: > > $ cd src > > src/ $ mkdir build > > src/ $ cd build > > src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. > > > > I'd like that to work. Would it work with your proposal ? > > Yes. > > > Once the cache is deleted in cmake-gui, I would expect that the values > > from the command line are also forgotten, also the -U values. Otherwise > > this cmake would remove the matching entries from every cache I load. > > True. (But what if that's what you want?) I think I would expect -U only to work if a cache is loaded initially, i.e. if cmake-gui is started with an existing build dir. 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] [CMake] Forwarding parameters to cmake through cmake-gui
Wouldn't it then be possible to write a simple shell script for those people who really want that use case which calls cmake with -U and afterwards call cmake-gui? Sorry if I didn't understood it as it was ment. For me the thing is: I prefer a simple solution which allows the same stuff which is possible with cmake itself (e.g. writing custom scripts which set default entries) and not to bloat the gui with stuff which are not used very often and can be achieved already with a combination of cmake/cmake-gui On Tue, Nov 5, 2013 at 9:40 PM, Matthew Woehlke wrote: > On 2013-11-05 15:14, physhh . wrote: > >> On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: >> >>> On 2013-11-05 14:36, Alexander Neundorf wrote: >>> Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. >>> >>> True. (But what if that's what you want?) >>> >> >> Could you give me a use case where u actuall don't want this? As already >> stated are the command line parameters the "default" values. >> If I dont' want to remove an entry by default I won't pass that parameter. >> If I want to remove an entry (but not by default) I will do it with the >> gui >> itself - That's what the gui is for? >> > > The use case is invoking cmake-gui "by hand" from a command line for a > specific project (i.e. specifying the build directory also on the command > line). > > As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to > work more like that. Whereas folks that are used to doing everything from > GUI's and hardly if ever touch a command line want it to work like we're > suggesting. Both points of view are IMO valid (though I tend towards > greater sympathy for the latter in this case). > > (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and > TBH, ccmake much more than cmake-gui - but I (try to) understand and > respect the non-CLI use case.) > > (¹ ...though not nearly as much as some people I know. I do prefer kwin > and kdevelop over ratpoison and vim/emacs, thank you ;-).) > > > -- > 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 15:14, physhh . wrote: On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the "default" values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The use case is invoking cmake-gui "by hand" from a command line for a specific project (i.e. specifying the build directory also on the command line). As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) (¹ ...though not nearly as much as some people I know. I do prefer kwin and kdevelop over ratpoison and vim/emacs, thank you ;-).) -- 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 Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: > On 2013-11-05 14:36, Alexander Neundorf wrote: > >> I tried the following a few times in the past and noticed everytime that >> it >> does not work: >> $ cd src >> src/ $ mkdir build >> src/ $ cd build >> src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. >> >> I'd like that to work. Would it work with your proposal ? >> > > Yes. > > > Once the cache is deleted in cmake-gui, I would expect that the values >> from >> the command line are also forgotten, also the -U values. Otherwise this >> cmake >> would remove the matching entries from every cache I load. >> > > True. (But what if that's what you want?) > Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the "default" values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? > > The biggest problem is, what if you run cmake-gui without specifying a > build directory? In that case, whatever comes up initially is as likely as > not *not* the directory you want to apply options to. > > 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). > > -- > 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 14:36, Alexander Neundorf wrote: On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote: Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both "UI". It would accept the same set of options: [...] -G = Specify a makefile generator. -T= Specify toolset name if supported by generator. Not sure about these two. I have to select them anyway when starting configure, I don't see much value in overriding this from the command line. Specifying them on the command line would allow you to skip the GUI dialog to select them. -- 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 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Yes. Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) The biggest problem is, what if you run cmake-gui without specifying a build directory? In that case, whatever comes up initially is as likely as not *not* the directory you want to apply options to. 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). -- 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] CMakeParseArguments: Do not skip empty arguments
On Tuesday 05 November 2013, Daniele E. Domenichelli wrote:
> Hello all,
>
> Current implementation of cmake_parse_arguments skips empty arguments.
>
> For example:
>
> cmake_parse_arguments("OPTION" "SINGLE" "MULTI" ${ARGN})
>
> with ARGN that is set using something like:
>
>SINGLE "" # (;SINGLE;;)
>SINGLE "" # (;SINGLE;)
>
> it will fail in 3 different ways:
>
> 1) because the "foreach" skips empty arguments
> 2) because list(APPEND ${currentArg}) will fail to append an
>empty element to the list if currentArg is an empty string.
> 3) because empty arguments are not passed to cmake_parse_arguments
>if not quoted, i.e. if ARGN="a;;b"
>* ${ARGN} will pass the arguments "a", "b"
>* "${ARGN}" will pass the arguments "a", "", "b"
Not sure about the third point. It could be done intentionally that way in
order to ignore empty strings.
> I wrote a small patch to fix this, you can find it in the
> CMakeParseArguments_EmptyArgs topic. This patch fixes the first
> behaviour using foreach(IN LISTS) version, the second by enclosing
> currentArg in quotes where required, and finally fixes the documentation
> in order to suggest to use quoted "${ARGN}" in order not to miss the
> empty arguments at the end of the list.
>
> 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 ?
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] [CMake] Forwarding parameters to cmake through cmake-gui
On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote: > Would it makes sense to have cmake-gui behaving like ccmake ? After all > there are both "UI". > > It would accept the same set of options: > > -C = Pre-load a script to populate the cache. > -D := = Create a cmake cache entry. > -U = Remove matching entries from CMake cache. I agree. > -G = Specify a makefile generator. > -T= Specify toolset name if supported by > generator. Not sure about these two. I have to select them anyway when starting configure, I don't see much value in overriding this from the command line. 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] [CMake] Forwarding parameters to cmake through cmake-gui
On Tuesday 05 November 2013, David Cole wrote: > >>> My question is still not answered completely: > >>> > >>> When should the new variable be added? On startup is not really > >>> possible because it might be the case that your src/binary directory > >>> is not set properly. > >>> > >>> So you would agree that it makes sense to do it "on configure" but > >>> only if the cache is empty? This will not allow to overwrite the > >>> variable via parameter but I guess that usecase is not very > >>> common? > >> > >> On startup is the only time it does make sense. After that, the user > >> should be in charge, and the command line settings should not be > >> re-applied again after a user makes an edit. You don't need the > >> src/binary directories set properly necessarily in order to add a > > cache > > >> entry to the UI. > > > > ... > > > > - What should happen with a -D option if there is not initially a > > build > > > directory selected? > > It should add UI entries even though there is no build directory > selected, and set them according to the -D values. Then, the -D values > should be forgotten about and never applied again during that session, > regardless of future user actions. > > Also, you could require that for -D args to work properly, the current > directory *is* the binary directory at startup time (just like cmake > and ccmake). If you're passing -D arguments to the gui program, then > you have control over its launching point, and can set the current > directory to be whatever you like. > > If launched without a build directory, you could choose the last known > build directory (if there is one) just like cmake-gui does now. > > If no build directory, no -D args. I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. 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
[cmake-developers] Ninja pools
I merged a proposal to next which adds support for Ninja's "pool":
http://martine.github.io/ninja/manual.html#ref_pool
It adds three new properties, POOLS, LINK_POOL, COMPILE_POOL:
http://www.cmake.org/cmake/help/git-next/manual/cmake-properties.7.html
With a "pool" it is possible to limit the number of concurrent
processes of a specific rule.
For instance if you have a project with multiple targets and
each target needs all your resources while linking (memory,
hard-disk bandwidth), it makes no sens to start multiple link
processes in parallel. To prevent this the pool feature was
introduced in ninja.
In concrete, with this patch:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 25cd576..d257c97 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -21,6 +21,8 @@ if(CMAKE_BOOTSTRAP)
unset(CMAKE_BOOTSTRAP CACHE)
endif()
+set_property(GLOBAL PROPERTY POOLS "compile=1")
+
if("${CMake_SOURCE_DIR}" STREQUAL "${CMAKE_SOURCE_DIR}")
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index c01245c..d7c68d5 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -393,6 +393,8 @@ target_link_libraries(CMakeLib cmsys
${CMAKE_TAR_LIBRARIES} ${CMAKE_COMPRESS_LIBRARIES}
${CMAKE_CURL_LIBRARIES} )
+set_property(TARGET CMakeLib PROPERTY COMPILE_POOL compile)
+
and the current next branch, ninja builds CMakeLib single threaded,
without passing -j1 to ninja.
Current patch adds only the essentials, but maybe there are more
comfortable ways to use pools.
Peter
--
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 for Mathews solution. To bad it's just on the developers list. I will simply cite him: On 2013-11-04 15:47, David Cole wrote: >>* My question is still not answered completely: ** When should the new variable be added? On startup is not really *>>* possible because it might be the case that your src/binary directory *>>* is not set properly. ** So you would agree that it makes sense to do it "on configure" but *>>* only if the cache is empty? This will not allow to overwrite the *>>* variable via parameter but I guess that usecase is not very *>>* common? *>>* On startup is the only time it does make sense. After that, the user *>* should be in charge, and the command line settings should not be *>* re-applied again after a user makes an edit. You don't need the *>* src/binary directories set properly necessarily in order to add a cache *>* entry to the UI. * There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. >* ccmake and cmake-gui *should* behave (in *my* opinion) as follows: *>* - on startup, load the CMakeCache.txt values (if there are any) from the *>* previous run *>* - then apply the -D arguments so that any -D arguments given on the *>* command line overwrite previous cache entries (just like command line *>* cmake does already) *>* - then put the user in charge and wait for user input * I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew On Tue, Nov 5, 2013 at 3:25 PM, David Cole wrote: > My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it "on configure" but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? >>> >>> On startup is the only time it does make sense. After that, the user >>> should be in charge, and the command line settings should not be >>> re-applied again after a user makes an edit. You don't need the >>> src/binary directories set properly necessarily in order to add a >>> >> cache > >> entry to the UI. >>> >> >> ... >> >> - What should happen with a -D option if there is not initially a >> > build > >> directory selected? >> >> > It should add UI entries even though there is no build directory selected, > and set them according to the -D values. Then, the -D values should be > forgotten about and never applied again during that session, regardless of > future user actions. > > Also, you could require that for -D args to work properly, the current > directory *is* the binary directory at startup time (just like cmake and > ccmake). If you're passing -D arguments to the gui program, then you have > control over its launching point, and can set the current directory to be > whatever you like. > > If launched without a build directory, you could choose the last known > build directory (if there is one) just like cmake-gui does now. > > If no build directory, no -D args. > > > > - What should happen if the wrong build directory is initially >> > selected > >> and subsequently changed? It seems non-desirable here to forget -D >> (etc.) entirely at that poin
[cmake-developers] CMakeParseArguments: Do not skip empty arguments
Hello all,
Current implementation of cmake_parse_arguments skips empty arguments.
For example:
cmake_parse_arguments("OPTION" "SINGLE" "MULTI" ${ARGN})
with ARGN that is set using something like:
SINGLE "" # (;SINGLE;;)
SINGLE "" # (;SINGLE;)
it will fail in 3 different ways:
1) because the "foreach" skips empty arguments
2) because list(APPEND ${currentArg}) will fail to append an
empty element to the list if currentArg is an empty string.
3) because empty arguments are not passed to cmake_parse_arguments
if not quoted, i.e. if ARGN="a;;b"
* ${ARGN} will pass the arguments "a", "b"
* "${ARGN}" will pass the arguments "a", "", "b"
I wrote a small patch to fix this, you can find it in the
CMakeParseArguments_EmptyArgs topic. This patch fixes the first
behaviour using foreach(IN LISTS) version, the second by enclosing
currentArg in quotes where required, and finally fixes the documentation
in order to suggest to use quoted "${ARGN}" in order not to miss the
empty arguments at the end of the list.
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?
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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it "on configure" but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ... - What should happen with a -D option if there is not initially a build directory selected? It should add UI entries even though there is no build directory selected, and set them according to the -D values. Then, the -D values should be forgotten about and never applied again during that session, regardless of future user actions. Also, you could require that for -D args to work properly, the current directory *is* the binary directory at startup time (just like cmake and ccmake). If you're passing -D arguments to the gui program, then you have control over its launching point, and can set the current directory to be whatever you like. If launched without a build directory, you could choose the last known build directory (if there is one) just like cmake-gui does now. If no build directory, no -D args. - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. No, it seems desirable to forget them at that point. They only apply to the build tree you launched it with. If you change the build directory, they do not apply. I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? Not really -- I think you're vastly over complicating the solution to a very simple problem. 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both "UI". It would accept the same set of options: -C -D := -U -G -T It would appear that ccmake is behaving incorrectly with respect to -D processing... http://public.kitware.com/Bug/view.php?id=14538 So I think avoiding the phrase "like ccmake" in this discussion would be a good thing. I do agree that ccmake and cmake-gui should behave the same with respect to these command line parameters. But I think ccmake is not the good example that we would want it to be... David C. -- 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
