[CMake] Re: Parsing cmake command line parameters

Brandon Van Every bvanevery at gmail.com
Tue Dec 18 12:41:43 EST 2007


On Dec 18, 2007 12:01 PM, Rodolfo Schulz de Lima <rodolfo at rodsoft.org> 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


More information about the CMake mailing list