[CMake] Parsing cmake command line parameters

[James Bigler]

> Rodolfo Schulz de Lima wrote:
>> Alexander Neundorf escreveu:
>>> If you can find some spare time, there is a command argument  
>>> parser in CMake/Source/kwsys/, which is used e.g. by cpack, but  
>>> not (yet) by cmake. Using this in cmake is the first step in  
>>> getting better support for custom command line parameters. A  
>>> patch would be very welcome.
>>> Currently I don't have the time.
>> I think I'll have some spare time to do this on this weekend, I'd  
>> be glad to help if there's enough coordination to avoid  
>> unnecessary work duplication.
>>> Second idea: maybe it would already help if the command line  
>>> arguments to cmake would be available via a special cmake variable.
>>> Is there anything which speaks against this, Bill ?
>> IMHO, we should differentiate between --enable/--disable and -- 
>> with/--without,  like it is on autotools' configure. The former  
>> used to enable/disable features, the other to compile with/without  
>> some external library.
>> There's also the ubiquitous --prefix that should be mapped to  
>> CMAKE_INSTALL_PREFIX, and the others that commonly appear when we  
>> execute 'configure --help'.
>> It should be nice to have a framework to facilitate working with  
>> enable/disable and with/without. The other common arguments that  
>> maps to cmake variables should be set up by default.
>
> The real problem with the command line arguments is how to gather  
> them up for a project.   I really have yet figured out a clean way  
> to do that.  People will want access to all options in the project,  
> but I don't see a way to do that...
>
> -Bill

What is it that people want beyond - 
DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE could provide?

Do they want: --enable-build_this_that_whatever?

I also don't understand why we have to parse the whole CMakeLists.txt  
structure.  We should treat these command line args like we cache  
variables like CPack does when you configure different builds.

James