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] [cmake-developers] 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 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
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 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
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] [cmake-developers] 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] [cmake-developers] 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 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
Re: [CMake] [cmake-developers] 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 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
Re: [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 Mon, Nov 4, 2013 at 4:57 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-02 07:58, David Cole wrote: physhh wrote: The question is: What is the expected behavior? ccmake and cmake-gui are interactive programs meant to prompt the user to fill in the cache values properly before typing 'c' or clicking 'Configure'. -D is a convenient way to give cache values an initial value that is different from their natural 'default' values. Using -D with ccmake and cmake-gui makes total sense, but it should only be used by the program to set the initial value that users see in the UI. After that point, the user should be in charge, and if he sets something different in the UI, the user value should win. I think Matthew's bug report is correct: the UI value should be used and then stored in the cache for subsequent runs. The -D values to ccmake and cmake-gui should only be used for initializing UI entries. Therefore, they should *NOT* be passed to the internal CMake instance used for configuring. My thoughts exactly. Thanks, David. -- Matthew -- 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 -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
So the bugfix would be to use the -D parameters, given to cmake-gui, when configuring a completely new project (= cache is empty/non existing)? That would make sense to me and shouldn't be hard to implement. On Sat, Nov 2, 2013 at 1:00 PM, David Cole dlrd...@aol.com wrote: -Original Message- From: J Decker d3c...@gmail.com To: physhh . phy...@gmail.com Cc: cmake cmake@cmake.org Sent: Fri, Nov 1, 2013 9:51 pm Subject: Re: [CMake] Forwarding parameters to cmake through cmake-gui sorry and I should ask; after reading a bit more context; why are you using cmake-gui if you have -D's to pass already? It can make sense if you have a script that your users can run that populate a handful of -D options automatically, but that still require users to set some other options via the UI that are hard to determine proper values for automatically. D -- 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
[CMake] Forwarding parameters to cmake through cmake-gui
I've already searched for a feature like this but was not able to find it. Then i've looked up in the cmake-gui source code but couldn't find anything related. What I'm looking for: If cmake is used directly from the command line, it's possible to pass a bunch of options ( http://www.cmake.org/cmake/help/v2.8.12/cmake.html#section_Options). This is nice because with this it's possible to use default settings - even if the cache get deleted. I'm actually really interested in this because it would be possible to set the CMAKE_MODULE_PATH variable via batch file - which is neat for custom find modules in custom locations. My Request: I would like to see a feature which makes it possible to pass command line options to cmake-gui which get forwarded to cmake when it gets called. To make this work the cmake-gui could look for parameters which look like forward-* (where the * is a cmake option name) and pass it to cmake. Are there any counter-arguments against this? In my opinion it would make things much cleaner. -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
Hi Jean, I'm not quite sure I've understood your feedback correctly. You mean it would be nice to add a panel to the gui which lists all forwarded options with description text? Will try to create a patch for this. Thanks for your time On Fri, Nov 1, 2013 at 3:52 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Physhh, I like the idea. Instead, a gui panel (with tooltips, doc, ...) should be autogenerated from the option associated to the corresponding cmake executable. Would be happy to review changes / patches. Thanks Jc On Fri, Nov 1, 2013 at 10:47 AM, physhh . phy...@gmail.com wrote: I've already searched for a feature like this but was not able to find it. Then i've looked up in the cmake-gui source code but couldn't find anything related. What I'm looking for: If cmake is used directly from the command line, it's possible to pass a bunch of options ( http://www.cmake.org/cmake/help/v2.8.12/cmake.html#section_Options). This is nice because with this it's possible to use default settings - even if the cache get deleted. I'm actually really interested in this because it would be possible to set the CMAKE_MODULE_PATH variable via batch file - which is neat for custom find modules in custom locations. My Request: I would like to see a feature which makes it possible to pass command line options to cmake-gui which get forwarded to cmake when it gets called. To make this work the cmake-gui could look for parameters which look like forward-* (where the * is a cmake option name) and pass it to cmake. Are there any counter-arguments against this? In my opinion it would make things much cleaner. -- 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 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
Hey Matthew, that's interesting. I'm currently at a windows only machine so i can't check out ccmake but can only lookup the source. It appears that ALL parameters get forwarded to cmake - at least that's what cmCursesMainForm.cxx:52 this-CMakeInstance-SetArgs(this-Args); looks to me. Why do you think that a simple forward is not enough? ccmake seems to do it exactly that way? On Fri, Nov 1, 2013 at 4:12 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-01 10:47, physhh . wrote: What I'm looking for: If cmake is used directly from the command line, it's possible to pass a bunch of options. This is nice because with this it's possible to use default settings - even if the cache get deleted. ccmake accepts e.g. -D options to set CMake cache variables. It... does appear that cmake-gui does not. That seems like a bug (or at least a missing feature that one would naturally expect to exist). I would like to see a feature which makes it possible to pass command line options to cmake-gui which get forwarded to cmake when it gets called. To make this work the cmake-gui could look for parameters which look like forward-* (where the * is a cmake option name) and pass it to cmake. I'm not sure a forward option makes sense... what would it mean to forward e.g. -P or -E? Rather, I think cmake-gui should just accept directly those options that make sense, e.g. -D, -U, -C, -G, -T and probably -W[no-]dev, the same way that ccmake does. (Besides, these should affect cmake-gui even before cmake is invoked, so merely forwarding them is actually insufficient.) -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
+1 for updating cmake-gui to work equally to ccmake But my opinion regarding CMAKE_MODULE_PATH is different. The problem is that alot of the default find-modules don't work because the dependency is not in the location where the find-module expects it. Currently there are only two workarounds: - Change the find-module directly so it works in the local environment - Change the CMakeLists.txt of the project - which is bad because it's just a LOCAL problem and the CMakeLists should be mostly independent of the environment. With the command-line option it's possible to setup a custom cmake-gui batch file once per computer which sets e.g. the CMAKE_MODULE_PATH to a directory with customized find modules. If one doesn't want to use custom find modules that's fine too but I think everyone should have the option to place dependent libraries wherever she/he wants. On Fri, Nov 1, 2013 at 4:56 PM, Bill Hoffman bill.hoff...@kitware.comwrote: On 11/1/2013 10:47 AM, physhh . wrote: If cmake is used directly from the command line, it's possible to pass a bunch of options (http://www.cmake.org/cmake/**help/v2.8.12/cmake.html#**section_Optionshttp://www.cmake.org/cmake/help/v2.8.12/cmake.html#section_Options ). This is nice because with this it's possible to use default settings - even if the cache get deleted. I'm actually really interested in this because it would be possible to set the CMAKE_MODULE_PATH variable via batch file - which is neat for custom find modules in custom locations. Branching the topic a bit. cmake-gui should most likely be updated to take the same arguments that ccmake and cmake take. However, if you are setting CMAKE_MODULE_PATH, the best place to do it is in the CMake code of your project. That way your project will stand on its own and not require special command line options to build (which is bad IMO). -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
Yes but not all cmake projects which I build are mine. So i would still have to modify a CMakeLists from someone else, which is in my opinion a bad thing. When you have the possiblity to inject cmake stuff without modifying the project itself you can implement a clean separation between project dependencies and how/where to find those. On Fri, Nov 1, 2013 at 5:28 PM, John Drescher dresche...@gmail.com wrote: +1 for updating cmake-gui to work equally to ccmake But my opinion regarding CMAKE_MODULE_PATH is different. The problem is that alot of the default find-modules don't work because the dependency is not in the location where the find-module expects it. Currently there are only two workarounds: - Change the find-module directly so it works in the local environment - Change the CMakeLists.txt of the project - which is bad because it's just a LOCAL problem and the CMakeLists should be mostly independent of the environment. With the command-line option it's possible to setup a custom cmake-gui batch file once per computer which sets e.g. the CMAKE_MODULE_PATH to a directory with customized find modules. If one doesn't want to use custom find modules that's fine too but I think everyone should have the option to place dependent libraries wherever she/he wants. For these kind of things I use environment variables in my CMakeLists.txt. If the environment variable is set I use it. If not I use the default behavior. John -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
I've tried to implement it in the same way as CCMake seem to do it. Because I can't compare it = Could somone with access to ccmake test this: - Start CCMake with -D foo=123 - Configure - Question: Is foo displayed in the variable list? - Add/Edit foo to some other value - Configure - Question: Was foo overwritten with 123? Thanks On Fri, Nov 1, 2013 at 7:02 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-01 11:39, physhh . wrote: that's interesting. I'm currently at a windows only machine so i can't check out ccmake but can only lookup the source. It appears that ALL parameters get forwarded to cmake - at least that's what cmCursesMainForm.cxx:52 this-CMakeInstance-SetArgs(**this-Args); looks to me. Why do you think that a simple forward is not enough? ccmake seems to do it exactly that way? I don't know enough of the guts to know how values initially specified in ccmake / cmake-gui get passed to CMake. Where you could get into trouble is, say, you pass -DBOOST_ROOT=/some/ptah, realize you've made a mistake (e.g. 'ptah' - 'path') and fix it in the gui before running cmake. Now does cmake see the original value or the corrected value? That's where it *might* go sideways. But it might also be perfectly safe to just pass them through, e.g. if the corrected value is passed also as a -D argument later in the list. However, what I was mainly getting at is that cmake-gui should also process the -D, etc., as I am pretty sure ccmake does, so that it can display those values and/or make appropriate use of the arguments. -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
Current patch: http://pastebin.com/DfGZtGQT On Fri, Nov 1, 2013 at 10:35 PM, physhh . phy...@gmail.com wrote: I've tried to implement it in the same way as CCMake seem to do it. Because I can't compare it = Could somone with access to ccmake test this: - Start CCMake with -D foo=123 - Configure - Question: Is foo displayed in the variable list? - Add/Edit foo to some other value - Configure - Question: Was foo overwritten with 123? Thanks On Fri, Nov 1, 2013 at 7:02 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-01 11:39, physhh . wrote: that's interesting. I'm currently at a windows only machine so i can't check out ccmake but can only lookup the source. It appears that ALL parameters get forwarded to cmake - at least that's what cmCursesMainForm.cxx:52 this-CMakeInstance-SetArgs(**this-Args); looks to me. Why do you think that a simple forward is not enough? ccmake seems to do it exactly that way? I don't know enough of the guts to know how values initially specified in ccmake / cmake-gui get passed to CMake. Where you could get into trouble is, say, you pass -DBOOST_ROOT=/some/ptah, realize you've made a mistake (e.g. 'ptah' - 'path') and fix it in the gui before running cmake. Now does cmake see the original value or the corrected value? That's where it *might* go sideways. But it might also be perfectly safe to just pass them through, e.g. if the corrected value is passed also as a -D argument later in the list. However, what I was mainly getting at is that cmake-gui should also process the -D, etc., as I am pretty sure ccmake does, so that it can display those values and/or make appropriate use of the arguments. -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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
Re: [CMake] Forwarding parameters to cmake through cmake-gui
The question is: What is the expected behavior? Execute it per configure but don't overwrite variables? What if one really wants to overwrite? Execute it once every time the binary directory changes? Changing stuff only through setting the path is bad. Other possiblities? On Sat, Nov 2, 2013 at 12:45 AM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-01 19:39, Matthew Woehlke wrote: On 2013-11-01 17:35, physhh . wrote: I've tried to implement it in the same way as CCMake seem to do it. Because I can't compare it = Could somone with access to ccmake test this: - Start CCMake with -D foo=123 - Configure - Question: Is foo displayed in the variable list? Yes. - Add/Edit foo to some other value - Configure - Question: Was foo overwritten with 123? Yes. Repeatedly (i.e. if I configure, then change it, it still gets overwritten). And I'm going to have to call that a bug; it's hard to imagine how it is desired behavior. Reported here: http://public.kitware.com/Bug/**view.php?id=14538http://public.kitware.com/Bug/view.php?id=14538 . -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://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.htmlhttp://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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
