[GRASS-dev] r.out.gdal rewritten

[Glynn Clements]

Martin Landa wrote:

> > it is bad to put any non parser code before G_parser():
> >
> >  http://article.gmane.org/gmane.comp.gis.grass.devel/12473/
> >  http://article.gmane.org/gmane.comp.gis.grass.devel/5224
> >  http://article.gmane.org/gmane.comp.gis.grass.devel/12446/
> >  http://article.gmane.org/gmane.comp.gis.grass.devel/7169
> >  ...
> 
> OK, you are right, on the other hand I don't know how to set
> format->options dynamically based on GDAL installation without coding
> before G_parser () function.

You can't.

> So might I ask you how to solve this problem?

In this case, you have to use GDAL to set up the option list before
calling G_parser().

It's more accurate to say that you shouldn't call other GRASS
functions (except for G_gisinit(), G_define_*()) before calling
G_parser(). It's safe to assume that functions from third-party
libraries will never be affected by command-line options.

Note that this still precludes dynamically generating option lists
using GRASS functions. That's inevitable; if you try to use GRASS
functions to generate option lists, the values which those functions
return might be affected by command-line options, so you end up with a
chicken-and-egg problem. This will become a major issue if we add
built-in options to G_parser() which allow global settings (e.g. 
environment variables or $GISRC settings) to be overridden.

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