On Mon, Jan 03, 2005 at 03:56:18PM -0500, Frank Warmerdam wrote: > > > 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. I don't see the problems in jpeg, png and tiff since most of these libraries should already be available on almost every system. It would be cool though not to be obliged to install libcfitsio2, libhdf4g and netcdfg3 just because I want to load some GeoTiffs. Currently this is necessary. > > 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. Ack. > > 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. Good news. I'm alwasy amazed how much you achieve to implement in a rather short time. Many thanks for all these efforts! > > 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? I my opinion the benefit is rather high but if you really expects to break the build chain by doing this is surely a drawback. I would have to spend some time to have a deeper look before I really can evaluate the problems so I am dependend on your opinion. What are the differences between creating a plugin for HDF and one for GRASS? BTW: The same discussion (about seperating some formats into special plugins) has been arosen on the Fedora side. So there seems to be interest by more than just a few people to have such a mechanism. Silke -- Intevation GmbH Georgstrasse 4 49074 Osnabrück, Germany http://intevation.de http://intevation.de/~silke FreeGIS.org http://freegis.org/
Attachment:
pgplrJc044NWP.pgp
Description: PGP signature