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] [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] [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 initial-cache -D var:type=value -U globbing_expr -G generator-name -T toolset-name 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
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 dlrd...@aol.com 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 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
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
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 initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. -U globbing_expr = Remove matching entries from CMake cache. I agree. -G generator-name = Specify a makefile generator. -T toolset-name = 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 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] [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 generator-name = Specify a makefile generator. -T toolset-name = 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 Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke matthew.woeh...@kitware.com 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 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
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 matthew.woeh...@kitware.com 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 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
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 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
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? (This is all my opinion, and may be mine alone, and should be discussed on the developer's list to see if it is shared by most other CMake devs, or if somebody objects to it for backwards compatibility reasons. I am adding the CMake dev list on the cc line...) 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. 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 This is, apparently, NOT the way that ccmake behaves today, but I think it should be changed to be like that. Please chime in, especially if you have a differing opinion. 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
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 11/04/2013 03:47 PM, David Cole wrote: 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 This is, apparently, NOT the way that ccmake behaves today, but I think it should be changed to be like that. I agree, and there is not too much concern for compatibility in this case due to the use of an interactive workflow. -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
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 -- 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 initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. -U globbing_expr = Remove matching entries from CMake cache. -G generator-name = Specify a makefile generator. -T toolset-name = Specify toolset name if supported by generator. Jc On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: 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 -- 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 -- +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
