[gdal-dev] Symbian Porting Issues

[Even Rouault]

Le Monday 05 January 2009 18:01:31 Mark Wilcox, vous avez écrit :
> Hi,
>
> First off, I must congratulate Frank and all the GDAL contributors on
> producing a fantastically portable library!  With just 2 days of effort
> starting from basically zero knowledge of GDAL I've got the core running
> and many of the raster formats building for Symbian OS.  I've even tested
> JPEGs and GeoTIFFs with a simple viewer application in the Symbian
> emulator.
>

Good to hear!

>
> Python is available on Symbian and Nokia have just released a new version
> (upgrading to 2.5.2 from 2.2) so I'll look and see if it's feasible to
> build and run the autotest stuff too as soon as I have time - is there much
> C/C++ test code other than that though?

There is some C/C++ code that lies in autotest/cpp directory, but it is not 
much maintened and used AFAIK. I would consider the python autotests as the 
reference test system for GDAL. They are a test for the python bindings of 
course, but also for the core functionnality and the drivers. Last time I 
measured, their coverage rate was 42.8% of the compiled code of my build 
(getting an extra .1% requires a non trivial amount of work ;-)). For GDAL 
and OGR core, port library, and tested drivers, it is typically between 60% 
and 80%. Non-tested drivers make the overall figure drop.

>
> 1) For some reason inflateCopy() is missing from the Symbian zlib port,
> even though it claims to be version 1.2.3 (existing library shipped in
> device firmware, not the internal copy in GDAL) at the moment I'm just
> excluding cpl_vsil_gzip.cpp from my build.  I'll try to get Nokia/Symbian
> to fix this and include the function in future releases.  I've seen some
> archive post that suggests maybe the same functionality could have been
> achieved without this dependency to support older versions of zlib
> though... is it worth reconsidering that option for Symbian support or is
> the gzip support not so commonly used?

./configure should normally default to internal zlib if it doesn't find 
inflateCopy symbol. But you could also discard cpl_vsil_gzip.cpp as it is a 
new functionnality to GDAL 1.6 and is somehow optionnal. (People can always 
uncompress their data at hand before running GDAL on them)
As far as not requiring inflateCopy() for the cpl_vsil_gzip functionnality, 
that could have been achieved, but the functionnality would not operate in a 
very efficient way then, so I've not strong motivation to support that.

Best regards,
Even