On Dec 18, 2007 12:01 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > > 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.
I disagree. Information hiding according to what's selected or possible is a perfectly valid way to interact with the user. Just because Autoconf listed every Tom, Dick, and Harry option "flatly" doesn't mean that CMake has to do it. The Autoconf listings are usually a bunch of boring boilerplate. The CMake approach is more powerful than what Autoconf provides; there are more ways for the programmer to cut off her fingers. So make the programmer responsible for what she does. Have a Chapter Oriented policy manual on how to implement command line options. Stress that if options are determined by complex conditionals, they're going to appear late in the help output. If the programmer wants the options to be readily apparent, she should determine them unconditionally or with constant conditions. A dry run through the CMake script is sufficient to determine any unconditional options. It's also sufficient for any conditions that are constants, such as the platform, generator, or compiler we're using. Or even variables that are defined early and don't change. Options that are masked by more complex conditionals can certainly be detected, and warnings can be issued about them. I think we need to stop thinking in terms of "perfect solution" and start thinking in terms of "policy," where the programmer is responsible for implementing a policy. > 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. Exactly. "Anything could happen" is a lot of fretting about nothing. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
