<div dir="ltr"><div>Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both "UI".<br><br></div><div>It would accept the same set of options:<br><br> -C <initial-cache> = Pre-load a script to populate the cache.<br>
-D <var>:<type>=<value> = Create a cmake cache entry.<br> -U <globbing_expr> = Remove matching entries from CMake cache.<br> -G <generator-name> = Specify a makefile generator.<br>
-T <toolset-name> = Specify toolset name if supported by generator.<br><br></div><div><br></div>Jc<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke <span dir="ltr"><<a href="mailto:matthew.woehlke@kitware.com" target="_blank">matthew.woehlke@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-11-04 15:47, David Cole wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My question is still not answered completely:<br>
<br>
When should the new variable be added? On startup is not really<br>
possible because it might be the case that your src/binary directory<br>
is not set properly.<br>
<br>
So you would agree that it makes sense to do it "on configure" but<br>
only if the cache is empty? This will not allow to overwrite the<br>
variable via parameter but I guess that usecase is not very<br>
common?<br>
</blockquote>
<br></div><div class="im">
On startup is the only time it does make sense. After that, the user<br>
should be in charge, and the command line settings should not be<br>
re-applied again after a user makes an edit. You don't need the<br>
src/binary directories set properly necessarily in order to add a cache<br>
entry to the UI.<br>
</div></blockquote>
<br>
There are two mostly separate issues here.<br>
<br>
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.<br>
<br>
As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all.<br>
<br>
It does however get more complicated...<br>
<br>
- What should happen with a -D option if there is not initially a build directory selected?<br>
<br>
- 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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ccmake and cmake-gui *should* behave (in *my* opinion) as follows:<br>
- on startup, load the CMakeCache.txt values (if there are any) from the<br>
previous run<br>
- then apply the -D arguments so that any -D arguments given on the<br>
command line overwrite previous cache entries (just like command line<br>
cmake does already)<br>
- then put the user in charge and wait for user input<br>
</blockquote>
<br></div>
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).<br>
<br>
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.<br>
<br>
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.)<br>
<br>
Make sense?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Matthew</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/<u></u>opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/<u></u>CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers" target="_blank">http://public.kitware.com/cgi-<u></u>bin/mailman/listinfo/cmake-<u></u>developers</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>+1 919 869 8849<br>
</div>