Re: [Pkg-grass-general] Plugin architecture of gdal
> > Maybe Debian developers should initiate refactorization
> > of GDAL leading to some kind plugin architecture? I can
> > offer my help.
Silke writes:
> In my opinion this is a rather good idea since I am not so happy as
> well about so the amount of dependencies of gdal. Nevertheless I
> would like to here your opinion about it and especially ask Frank
> what he thinks about the consequences of the build mechanism of
> gdal. Will it be very difficult to create a seperate plugin for
> each gdal and ogr format similar as this has been done for grass?
Marek / Silke,
First, I assume the issue that is bothering you is the
number of external library dependencies, is that right?
If so, there is no reason to make all formats plugins. Only
those that depend on optional external libraries. So this
might include stuff like HDF, FITS, GRASS (done), NetCDF,
OGDI, and even those formats for which internalized versions
of the support libraries are available like png, jpeg and tiff.
Formats for which all the code is always within GDAL
need not be built as plugins. For instance Erdas Imagine,
or any of the "raw" formats like ESRI BIL.
There is no auto-load a driver plugin from a shared library
option on the OGR side at this time. I intend to incorporate
one, but it will be done as part of unifying the driver architecture
with the GDAL driver architecture for GDAL 2.0. I don't want
to invest effort on it in the meantime.
Changing things to support building formats as plugins is
essentially a matter of working on the makefiles, and
configure scripts. For GRASS we wanted to hold off on building
the GDAL GRASS driver till after GDAL and GRASS has both
been installed. Since GRASS depended on GDAL I made a
whole seperate package for the GRASS driver. That should
not be necessary for other drivers where the external library
does *not* depend on GRASS. But we do still need a
way of instructing configure to build the module as a shared
library, instead of linking it into the main GDAL object code.
Amoung other things, I am not exactly sure how easy the
libtool related aspects of this will be.
The thing I fear out of this is alot of complication (and even
breakage) in the build stuff with relatively little real benefit.
How convinced are we that the pain is worth while?
> BTW: Is there any documenation how the plugin mechanism works for
> gdal? So far I have only been able to produce the grass plugin
> because Frank did seperate it.
The documentation in the AutoLoadDrivers() method of
the GDALDriverManager is pretty much all the documentation
that is accessable.
http://www.gdal.org/classGDALDriverManager.html
There isn't really any "build" documentation because there
is no build support for it at this time.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Reply to: