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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev