Brandon Van Every wrote: > On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> 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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
