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

[Matthew Woehlke]

On 2013-11-05 09:25, David Cole wrote:
> Matthew Woehlke wrote:
>> - 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.
> [...]
> I think you're vastly over complicating the solution to a very simple
> problem.

If you read physsh's question that lead to this:

>>>> 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.

...it seems very explicit that your proposal is inadequate for his use case.

Besides, I don't think the parallel holds: cmake-gui != ccmake.

In ccmake, there is no concept of choosing / changing the build 
directory - one *must* run it with $PWD == ${CMAKE_BINARY_DIR} - so it 
makes sense to only apply -D/etc. to the initial build directory.

This is very much not the case with cmake-gui; it might be launched from 
a desktop / launcher menu shortcut where all bets as to $PWD are off, 
and anyway it may not even start with $PWD as the build directory.

The ability to change the build directory after launching, which is 
unique to cmake-gui, is IMHO very much worth handling -D/etc. options 
differently for that reason.

Again, looking at physsh's comments, I think we should be considering 
the case of someone that wants to always pass the same -D/etc. arguments 
'by default'. One might conceivably (expect to be able to) do this by 
modifying the cmake-gui shortcut to include the desired options. For 
that to work, cmake-gui would need to apply the options to any 
newly-configured project, even if it wasn't the initially selected 
project. (For that matter, one might conceivably want to configure 
several projects, or at least several build directories, in one 
'session', with the options applied to all of them.) I think this is a 
very reasonable use case that should be supported, and I tried to 
address that in my proposal.

-- 
Matthew