[GRASS-dev] [GRASS-SVN] r60703 - in grass/trunk: display/d.vect general/g.gisenv gui/wxpython/animation lib/python/temporal raster/r.colors raster/r.external raster/r.in.bin raster/r.mapcalc raster/r.neighbors raster/r.out.bin raster/r.quant raster/r.resamp.filter raster/r.series raster/r.series.accumulate raster/r.series.interp raster/r.stats.quantile vector/v.colors vector/v.external.out

[Glynn Clements]

Huidae Cho wrote:

> I was thinking about the same thing. Maybe add char *exclusive_group to
> Option and Flag and G_parser() takes care of exclusiveness?

There are two relatively straightforward cases for option
interdependencies:

1. At most one option from a set may be provided (mutual exclusivity).

2. At least one option from a set must be provided (more general form
of the ->required field).

Both of these requirements may apply, i.e. exactly one option from a
set must be provided.

But there may still be cases where that isn't sufficient, and you'd
need generalised boolean expressions. E.g. Where you need either A or
both of B and C. Or if you use A then B is required, otherwise it's
invalid.

It would be a fairly simple matter to add a function to evaluate a
boolean expression supplied by the module. But that wouldn't be much
help either to the GUI (which ideally would use the interdependency
information to e.g. grey out invalid options) or for generating error
messages (we want something more informative than "that combination of
options isn't valid").

So, in the first instance I'd suggest adding:

	// at most one option from a set
	void G_option_exclusive(const char *opt, ...);

	// at least one option from a set
	void G_option_required(const char *opt, ...);

	// if the first option is present, at least one of the other
	//  options must also be present
	void G_option_requires(const char *opt, ...);

All functions take a NULL-terminated list of option/flag names
(leading "-" indicates a flag).

The argument-checking code would be migrated to the new functions. Any
cases which still cannot be expressed would be reported to the list
for further consideration.

Once we've either covered all of the cases or concluding that any
remaining cases cannot reasonably be incorporated into any general
framework, we can work on exporting this information via
--interface-description etc.

-- 
Glynn Clements <glynn at gclements.plus.com>