[cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
David Cole
dlrdave at aol.com
Tue Nov 5 09:25:58 EST 2013
>>> 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
More information about the cmake-developers
mailing list