Re: [Pkg-grass-general] Plugin architecture of gdal
Hi,
User Frank Warmerdam wrote:
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?
Right. Particularly, the dependencies on commercial libraries like OCI
(OGR level :-) ) are
painfull.
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.
Sure. Things implemented internally by GDAL do not need to be plugins.
There is no auto-load a driver plugin from a shared library
option on the OGR side at this time.
Problem with OCI exists OGR part of GDAL.
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.
Great news! When GDAL 2.0 is to be released?
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.
Right, most of work is on configuration management level. But not only.
For example
many header files should also be modified, because Windows shared
libraries,
needs their own export macros.
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.
There is a number of build tools providing such support for many platforms
mutually. I used MakeProjectCreator (there is mpc-ace package for
debian) which
resembles in a way CMake. MPC can generate platform specific build files
eg. vcprojs
for MSVC or GNUmakefile for gmake and handle all platform details.
There is also
lot of various build systems for which directly invoke specific
compilers like scons or bjam.
They are very flexible, which is good, but a little more advanced. In
general, separate built
files for various platform make configuration management harder, hence I
propose
to change the way GDAL is compiled.
The thing I fear out of this is alot of complication (and even
breakage) in the build stuff with relatively little real benefit.
In my opinion a good plan and good build tool can protect us from
complications and bugs :-)
How convinced are we that the pain is worth while?
Hard to argue reasonable. But I'll try.
There was a time I used various makefiles, dsp, vcproj for various
platforms, and beyond 20KLOCs I
realized that I spent more time on configuration management than on
coding. In long term, especially for
multiplatform libraries the benefits are for me rather obvious, because
build files prepared for one platform work
(usually) under all remaining architecture Moreoever, good build tool
eliminates many silly bugs like incompatible
DLLs for windows. My personal experience from observing a small team of
developers is that many
problems they were implied by a bad build system eg. IMHO M$VC concept
of workspaces and
projects does not support developement in teams greater than few
individuals.
The main benefit of plugin architecture is a better distribution of
GDAL. For example, now I have
to compile the entire GDAL after each new version, because OCI support
cannot be distributed by Debian. With a
plugin architecture I should compile only OCI support. Moreover, one can
image that some precompiled, probably
non-free plugins could be avalaible in various archives distinct from
the Debian one.
The next advantage is the lower footprint of GDAL based application. For
example, many application do
not need postgres support, but without plugins they have to depend on
postgres libraries. There is a lot of
applications which run in constrained enviroment, and I see no reason to
force then to have separately
prepared GDAL distribution.
I think that the developer using GDAL should almost never compile GDAL,
but rather use prepared distributions.
This makes develepement faster, and moreover the quality of the
resulting application may be higher as the
package maintainer usually better compiles GDAL than an average programmer.
Best regards
Marek Brudka
Reply to: