Re: [Pkg-grass-general] Plugin architecture of gdal
Frank Writes:
>>Marek / Silke,
>>
>>First, I assume the issue that is bothering you is the
>>number of external library dependencies, is that right?
Marek writes:
>Right. Particularly, the dependencies on commercial libraries like OCI
>(OGR level :-) ) are painfull.
Well, as mentioned I am not eager to provide auto-loading support on the
OGR side at this time, which kind of leaves you in a lurch if you need
the OCI driver.
>>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 am not prepared to commit to any sort of timeline. Likely within a
couple of years. Maybe a couple of months.
>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.
I'm afraid I don't follow this aspect. What do you mean about export
macros? I normally insert CPL_DLL in the prototypes of any function or
class I wanted exported from the DLL. Amoung other things this applies
to the registration entry point for the drivers, and would not change.
>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
I am not prepared to contemplate a change of build infrastructure. I have
alot of effort invested by myself and others in the current approach and
I am not eager to try and reproduce it in a new environment. My current
approach is to stick to configure/GNUmake on all platforms and to offer a
seperate build infrastructure for those with Visual Studio (in the form of
NMAKE files). The complex part is really all the configure/libtool magic.
My concern is that to (optionally) make some drivers buildable as plugins
will further complicate the configure options and mean I need shared library
building "stuff" in a bunch more places.
> 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.
Well, this is a pretty compelling argument. In fact, it would be nice to
be able to add a single plugin to any of the binary distributions including
my own FWTools.
> 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.
Note, all you depend on are the postgres client side libraries which are quite
small. Other, more compelling cases are OCI, HDF, OpENDAP, and OGDI which
all drag in quite a bit of stuff. However, in this modern age, I don't
think this sort of bloat is really a big performance issue for most folks.
> 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.
Well, I don't really agree with the "almost never" though for simple cases it
is nice to use a pre-built set of libraries. However, you don't have to get
very far before it is very desirable to build your own copy of the
libraries so you can debug into GDAL when needed. While I am proud of GDAL
I am also realistic that it has it's share of bugs and also lots of weakness
in the docs. The ability to debug down into what I hope is fairly readable
code is a big plus in quickly working out problems. Also, there are many
developers using GDAL who find it helpful to tweak things inside GDAL.
Silke writes:
> 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.
Agreed. How be to start, I look at making it easy to build some of
the raster formats with substantial external dependencies as plugins.
> 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?
Well, HDF is easier because we don't have to make it a seperate build
process with it's own configure and makefile as we did for GRASS. But
to make the regular GDAL build (optionally) build it as a plugin will
add complication. And in my experience any trivial change to the unix
build process has about a 50% chance of introducing an additional bug.
A non-trivial one like this has about a 150% chance of introducing a bug.
:-)
> 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.
Agreed.
OK, so I will proceed to make some of the noteworthy raster drivers
support building as a plugin. The more I think about it, the more I
also now feel I should allow plugin support for OGR now, instead of waiting
for the GDAL 2.0 "grand unification".
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: