Re: [Pkg-grass-general] Plugin architecture of gdal
Hi,
User Frank Warmerdam wrote:
I am not prepared to commit to any sort of timeline. Likely within a
couple of years. Maybe a couple of months.
I'm patient, at least I think so :-)
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.
If you do not plan to use plugins like any other dynamic library, then
single macro is enough.
Moreover, for Win32 this macro is even not needed as one does not have
to swich between decl(export)
and decl(import). Obviously, for multiplatform programs this macro is
necessary to eliminate those
MS extension for compilers like gcc.
But if plugin is also a plain DLL with it's own import library, then one
should apply the rule: separate macro
for separate DLLs. This is the simple way to ensure that in build
systems for large projects symbols are
exported/imported exactly as needed. I paid a fee for learning this
once, and as I realized later it is a common
practice for many developers (see eg. ACE/TAO library)
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.
I estimate that changing the build system can take a volunteer like me
about a month.
The first result of this will be simplied built of shared libraries and
the second one simplified
configure scripts. Hmm, what about the proof of concept for a part of GDAL?
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.
When one considers all those PC with huge disk and GB of RAM, then this
is not important.
But I can imagine using GDAL in embeded applications like industrial PC
board (VME, PC104 etc)
and all those funny gagdets like palmtops, GPS receivers or GSM phones?
But these devices has
usually limited resources and each additional MB of flash of HDD means
additional costs.
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.
My opinion is based on observing the teams of developers. While
developers working "near" GDAL eg.
responsible for drawing maps usually compile GDAL because they sometimes
need to debug GDAL
interiors. On the contrary the programmers, tester etc. responsible for
other things love precompiled
versions and libraries ready out of the box, because they neither like
nor have time to compile GDAL.
Moreover some of them even do not want to know anythign about GDAL, it
is enough for them to have
preconfigured environment to work. I hope I explained better my point of
view :-)
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".
Great! Please tell me if I could help.
Regards
Marek Brudka
Reply to: