[CMake] Re: Parsing cmake command line parameters

[James Bigler]

Rodolfo Schulz de Lima wrote:
> Alexander Neundorf wrote:
> 
>> I have (currently) two ideas:
>> either a special file, e.g. CMakeCustomArgs.txt, which in some way 
>> sets up the custom command line parameters.
> 
> There's a beauty in having everything inside CMakeLists.txt

Not only that, but this becomes a maintenance nightmare.  It's too easy to get these out of sync.

>> Or have a cmake modules, which handles this stuff, and which also 
>> creates a custom target "help-args" or something like that, which 
>> prints the available args. This would not be available before cmake 
>> has successfully run.
> 
> This would be non-intuitive to people not accustomed to cmake.

This isn't a problem if it's documented well.  If "cmake --help" spit out something told the user what to do, they will usually do it.  The problem lies when the programs don't 
behave as expected with no explanation (i.e. Using -DMY_VAR=value instead of -DMY_VAR:STRING=value should be rejected instead silently doing weird things).

Having a good README or INSTALL file does wonders.  That's the first thing I look for in a project.

> 
> I think that the scope of where argument definitions should be defined 
> should be well defined. The example I gave of each cmake --help 
> evocation returning a different set of arguments shouldn't be allowed.
> But it's reasonable to create some arguments when cmake is running under 
> Windows or Linux, etc. And let's not forget that maybe 80% of all uses 
> of command line arguments will be the most trivial one, i.e., statically 
> define those arguments, so sticking with like 90% of all use cases would 
> be good enough, IMHO.
> 
> wxWidgets' configure script throws all possible options, whether they're 
> valid for Windows or Linux. It's really a mess, but it's simple to 
> implement and I've never heard of anyone complaining about it.

So this isn't so much a discussion of being able to parse arguments from the command line, but rather an automated mechanism to detect options in the CMakeLists.txt files and print 
them out when a user does --help.

Many autoconf systems don't do this.  To see the "real" options I have to scan configure.in myself.  For autoconf build systems I have generated, I have to manually add the help 
options.  I think it's silly to try and solve this problem, especially when there is a much better way to do it via ccmake.  I much prefer using ccmake than having the giant 
configure line.

It seems like CMake already has a good way to configure builds, and those used to autoconf just need a little nudging.  I haven't had anyone in my group complain about using ccmake.

That being said, if you really want cmake --help-options, then I guess you would just have to parse all the CMakeLists.txt files, find all occurrences of ADD_ARG() regardless of 
scope, and spit them out.  There really isn't a better option outside of just using ccmake.

James