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

[tlaronde at polynum.org]

Hello,

Quoting Paul Kelly <paul-grass at stjohnspoint.co.uk>:


> > 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.

OK.


> > 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.

I agree, the main problem is that, at least, we must verify that the library
we are just about to link against matches the API use by the code, i.e. that 
the prototypes are correct but this can only be achieved if this the gdal
package which installs the headers needed (it should be so since gdal installs
also statically linked library which are typically used when compiling...).

> 
> ...
> > 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. 

Thanks for the tip!

Cheers,