Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 11/04/2014 06:38 PM, Eric Wing wrote: > This would be really useful to me. No one plans to work on it AFAIK. You'd have to dig in yourself. Sorry, -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://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
Bump. With CMake 3.1 on the horizon, I was wondering if there was any progress on this. This would be really useful to me. I am basically invoking command line cmake.exe so I can pass all the right options, including my own CMake Initial Cache file. I ship an entire self-contained "SDK" of sorts which has all the prebuilt library dependencies in a place relative to a .bat or .sh script used to invoke cmake.exe, which makes project generation for all of my platforms essentially a turn-key operation. However, my projects have a couple of configurable options (e.g. I don't need to link in OpenAL), And it would be nice if I could present the CMake gui first so they can uncheck the options before generation. (I copy some things into the build directory on generation which means they get stuff they may not want if they can't uncheck the option first.) I think basically the behavior I want is essentially the same as ccmake, except have a proper GUI (a lot of Windows and newer users don't grok the curses thing). Thanks, Eric -- 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://public.kitware.com/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 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
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
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 wrote: > > > > 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 > -- 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] [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
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
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
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 = Pre-load a script to populate the cache. -D := = Create a cmake cache entry. -U = Remove matching entries from CMake cache. -G = Specify a makefile generator. -T= Specify toolset name if supported by generator. Jc On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke 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
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
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
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
