[CMake] --enable-* with cmake

[Philip Lowman]

Brandon Van Every wrote:
> On 8/8/07, Philip Lowman <philip at yhbt.com> wrote:
>> I love CMake, but there have been times when I wished that
>>
>> --enable-foo would simply be a shortcut to set a boolean variable
>> ENABLE_FOO to true.
> 
> Some would say that's not nice because you don't get exactly what's on
> the command line.    By the logic of exactitude, --enable-foo should
> define enable-foo to true.  And if I wanted ENABLE_FOO, then I'd put
> --ENABLE_FOO on the command line.  Or I could put -DENABLE_FOO,
> couldn't I?  ;p  My point is that --enable-foo is an Autoconf
> convention, nothing more.  It's mainly about making an Autoconf
> migration crowd happy.

Actually, it's more like this:

cmake -D USE_FOO=BOOL:ON .
or
cmake -D USE_FOO=BOOL:OFF .

I don't know where -DUSE_FOO or -D USE_FOO came from, it doesn't appear
to be legal in 2.4.6.

$ cmake -DUSE_FOO .
Parse error in command line argument: -DUSE_FOO
Should be: VAR:type=value
CMake Error: No cmake scrpt provided.
CMake Error: Problem processing arguments. Aborting.

$ cmake -D USE_FOO .
Parse error in command line argument: -D
Should be: VAR:type=value
CMake Error: No cmake scrpt provided.
CMake Error: Problem processing arguments. Aborting.

The fact that people don't even know the proper way to define variables
at the command line (myself included) should be proof positive that
CMake could use some improvement when operating in command line mode.

Should these improvements manifest themselves it might make sense to
format them around existing autoconf conventions to ease transition by
people that prefer the command line.

-- 
Philip Lowman
Simulation Development Engineer, Modeling and Simulation Technology
General Dynamics Land Systems
http://www.gdls.com