[CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui

[Jean-Christophe Fillion-Robin]

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.woehlke at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20131104/a61e72b1/attachment-0001.htm>