[GRASSLIST:758] Re: FIX: gdal/v.in.dgn support with grass 5.0.2

[Paul Kelly]

Hello

On Sun, 20 Jul 2003, Thierry Laronde wrote:

...
> Since the integration of the dgn library in gdal, the API has changed
> and several things need to be adjusted for the module v.in.dgn (for
> instance, DGNOpen now takes 2 arguments).

It looks like this is already fixed in the CVS v.in.dgn.

...
> To verify the presence of the DGN* functions one can use `nm' but a test
> should be inserted in the configure script (I'm not an autoconf user, so
> the patches are not given).

I think if OGR support is in GDAL then it will be there. The GRASS 5.1 (to
be 5.7.x) configure script checks for `gdal-config --ogr-enabled`. Something
similar could be added to the 5.3.x configure and then the v.in.dgn module
compiled optionally.

> One problem with `gdal' is that the dgn* headers are not installed. I
> have so added the relevant headers directly in v.in.dgn subdirectory,
> but the "right" solution should be the installation of these by gdal.

I think that is the main problem. Everything else seems fairly simple to
tidy up. It looks like you need to have a full GDAL source installation if
you want to compile this, or maybe the headers for the DGN functions could
be included in the installed GDAL headers instead of GDAL installing even
more header files. A temporary solution would be to include copies of the
dgnlib.h and dgnlibp.h with GRASS, depending on what other developers
think.

The Gmakefile should probably have a reference to $(GDAL_CFLAGS) in the
EXTRA_CFLAGS. Then cpl_conv.h wouldn't need to be copied over as that *is*
installed with GDAL.

...
> afterwards ---BTW, how could one have it compiled by default if gdal
> support is selected at configure time?).

You would use the src/CMD/lists/optional / optional.in and the
LOC_OPTIONAL macro in the configure.in file I suppose. Probably r.in.gdal
should eventually be done like this as well. 

> Just a note : since `gdal-config --libs' mixes LDFLAGS (-L) and library
> argument (-l), a dependency against GDAL_LIBS was puzzling gmake.

The CVS version of the Gmakefile and main.c seem to be different from the
ones your patches are against so it doesn't make sense to comment on the
other things.

Paul Kelly