On 8/8/07, Philip Lowman <[EMAIL PROTECTED]> wrote: > > In defense of the original post, > > --enable-foo is much more readable than -DENABLE_FOO or -DUSE_FOO.
No it isn't, and it's not much of a defense. "Slightly more readable" I'd accept. Let's refrain from religious hyperbole when contemplating feature requests. The reality is any time you learn a new tool, you have to do things a new way. > 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. Should we make 'em happy? I don't know. On the one hand, the Autoconf crowd routinely complains about command line features. CMake isn't as oriented to the command line, maybe it could use work there. On the other hand, I believe that people who actually have to get projects done, learn what they need to learn and get on with it. It's one thing to play with a new tool and make complaints about it. It's another to know for fact that you have to port your build to several platforms including MSVC, and know that CMake is a far better tool for the job. My point is, we don't need to convert people who already know for fact that they need CMake's capabilities. Maybe there's a 3rd class of users I haven't considered. People who have been handed the job of doing a CMake build, but who didn't originally make the decision, and who don't spend their time on more than one platform. So they see CMake through "Linux only" eyes for instance, because that's the part of the build they're personally responsible for. There's also a "Windows only" crowd who sees CMake primarily in terms of how MSVC support could be improved. So maybe it's worth keeping these kinds of people happy, even though they raise what I personally would call "superficial objections." If their requests aren't a lot of work and don't do any harm. It would increase the body count of people who speak positively of CMake. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
