Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both "UI".
It would accept the same set of options: -C <initial-cache> = Pre-load a script to populate the cache. -D <var>:<type>=<value> = Create a cmake cache entry. -U <globbing_expr> = Remove matching entries from CMake cache. -G <generator-name> = Specify a makefile generator. -T <toolset-name> = Specify toolset name if supported by generator. Jc On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke <matthew.woeh...@kitware.com > wrote: > On 2013-11-04 15:47, David Cole wrote: > >> My question is still not answered completely: >>> >>> When should the new variable be added? On startup is not really >>> possible because it might be the case that your src/binary directory >>> is not set properly. >>> >>> So you would agree that it makes sense to do it "on configure" but >>> only if the cache is empty? This will not allow to overwrite the >>> variable via parameter but I guess that usecase is not very >>> common? >>> >> >> On startup is the only time it does make sense. After that, the user >> should be in charge, and the command line settings should not be >> re-applied again after a user makes an edit. You don't need the >> src/binary directories set properly necessarily in order to add a cache >> entry to the UI. >> > > There are two mostly separate issues here. > > As far as the bug, the ccmake behavior is (IMO, but seems generally > shared) is just wrong. physhh's questions (above) don't apply to this case > because there is no concept of interactively selecting the build directory > in ccmake. So fixing this is, if not easy, at least easy to understand how > it should behave. > > As far as cmake-gui, there are no backward compatibility issues because > right now it just doesn't support -D at all. > > It does however get more complicated... > > - What should happen with a -D option if there is not initially a build > directory selected? > > - What should happen if the wrong build directory is initially selected > and subsequently changed? It seems non-desirable here to forget -D (etc.) > entirely at that point. > > > ccmake and cmake-gui *should* behave (in *my* opinion) as follows: >> - on startup, load the CMakeCache.txt values (if there are any) from the >> previous run >> - then apply the -D arguments so that any -D arguments given on the >> command line overwrite previous cache entries (just like command line >> cmake does already) >> - then put the user in charge and wait for user input >> > > I suppose if I were writing the patch, I would have cmake-gui remember > whatever -D/-U/etc. options are given and apply them to any build directory > when it is selected, after loading the cache (if any). But *don't* pass > them on the cmake (except inasmuch as the initial cache will contain them, > modulo any changes the user made in the mean time). > > IOW, if I specify a -D to cmake-gui, change that value, then change to > some other build directory, that -D would reset to the value from the > command line. This is consistent with the current behavior that any other > changes to the cache of the initial build directory are also lost. > > Hmm... a corner case comes to mind, however; if I configure build > directory A after changing a -D value, then switch to build directory B, > then back to A, I probably don't want to reapply the -D. So maybe cmake-gui > would keep track of what build directories have been configured in that > instance and not apply -D/etc. to them. (However, it's probably not very > common for that to happen.) > > Make sense? > > -- > Matthew > > > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > -- +1 919 869 8849
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
