Nikos Alexandris wrote:
> What is the common practice for this? Define both options as optional
> and do the necessary checks inside the script? Or, is there a way to
> override options if another option is given in the definition-header?
Marking an option as "required" will result in the parser raising a
fatal error if the option is not given, with one exception: if a flag
has the suppress_required option, and that flag is given, all
requirements are ignored. This feature is intended for flags which
abandon "normal operation" for the module; e.g. r.in.gdal's -f flag
(list supported formats) uses it.
But in general, you cannot mark an option as required if it is
optional except for the special case of a suppress_required flag.
Historically, the solution was to make the option not requrired, then
explicitly check the combinations in the code, e.g. (for C)
if (!(altitude->answer || elevation->answer))
G_fatal_error(_("either %s= or %s= must be given"),
altitude->key, elevation->key);
However, GRASS 7 now has the ability to specify option relationships
to the parser. For C, the relevant functions are those in
lib/gis/parser_dependencies.c.
For scripts, relationships are specified using a "rules" section, e.g.
#%rules
#%required altitude,elevation
#%end
specifies that at least one of those options must be given. Both
options and flags can be specified (a leading "-" denotes a flag).
The available rule types are:
exclusive - at most one of the options may be given
required - at least one of the options must be given
requires - if the first option is given, at least one of the
subsequent options must also be given
requires_all - if the first option is given, all of the
subsequent options must also be given
excludes - if the first option is given, none of the
subsequent options may be given
collective - all or nothing; if any option is given, all must
be given
Note that the "required" rule was overlooked from g.parser; I've just
committed a fix now in r62850.
--
Glynn Clements <[email protected]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
