[CMake] Can CMake prompt the user for input while it's running?

[Naram Qashat]

On 02/28/10 11:52, Eric Noulard wrote:
> 2010/2/28 Bill Hoffman<bill.hoffman at kitware.com>:
>>
>>>
>>> Off course the cmake UI would authorize to unfilter all vars
>>> just as today there is the advanced/normal view.
>>
>> You could just use the advanced/non-advanced to handle this. When you want
>> to show a variable to the user make it non-advanced.  This would work with
>> ccmake, cmake -i, and cmake-gui.  They all default to showing non-advanced
>> variables by default.
>
> As far as I understand Naram needs he wants to show far less variable
> shown by cmake today (including vars coming from find_package(whatever))
>
> Not mentionning the fact that mark_as_advanced makes the variable a CACHE
> one which is not necesseraly what you want. You may even want to have a CACHED
> variable shown to the user.
>
> Basically I think you (Bill) are right the current "advanced" var
> should be enough
> but I doubt it correspond to Naram needs. I may be wrong, thus let Naram explain
> himself :-)

Well, using cmake -i might work for me, but I'm not sure if the format it shows 
the information in would be any less confusing to our users.  It'd be nice if 
CMake didn't have to show the variable name and could just show the description. 
  The people using our program are not the brightest bunch of people around, and 
I wish I was exaggerating this.  Right now we rely on a separate shell script 
(and a CScript file for Windows) to pre-configure in order to get information 
from the users in order to configure through CMake, but as I mentioned in my 
first e-mail, this won't help if we have a variable amount of files that I want 
to ask for prompting from the users on.

Now, a side thought I had, could I create a CMake file that can be run through 
cmake -P in order to determine any options I might need, and pass that as output 
that our pre-configure script can handle from there?  This might be an option if 
I can't handle this through CMake entirely.

Thanks,
Naram Qashat