[gdal-dev] GDAL trunk compilation broken by r19335 / minizip / libkml

[Harsh Govind]

I just checked the link and seems like the build is broken on szekerest-vc80-full. It cannot find ioapi.h which should be present in minizip include directory. I compiled the minizip as a library. Below are the commands I used in order to build minizip in VS2005 Command Prompt:

@echo off
setlocal enableextensions enabledelayedexpansion 
set MSVCPLATFORM=win32
set THIRDLIB=C:\sdk
set MINIZIPDIR=%THIRDLIB%\minizip

set DEBUGDIR=debug
set RELEASEDIR=release

vcbuild /rebuild /useenv /platform:%MSVCPLATFORM% minizip.vcproj "Debug"
vcbuild /rebuild /useenv /platform:%MSVCPLATFORM% minizip.vcproj "Release"

xcopy /I /Y /C /Q src\*.h %MINIZIPDIR%\include

xcopy /I /S /Y /C /Q %DEBUGDIR%\minizipd.lib %MINIZIPDIR%\lib
xcopy /I /S /Y /C /Q %RELEASEDIR%\minizip.lib %MINIZIPDIR%\lib

endlocal


I will add auto-tests for this driver soon.

Regards,
Harsh Govind
________________________________________

From: Tamas Szekeres [szekerest at gmail.com]
Sent: Wednesday, April 07, 2010 06:16 PM
To: Even Rouault
Cc: Harsh Govind; gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] GDAL trunk compilation broken by r19335 / minizip /     libkml

2010/4/7 Even Rouault <even.rouault at mines-paris.org<mailto:even.rouault at mines-paris.org>>
(2) : It also enabled me to experiment with adding support for ZIP64
unzipping. Very recently (15 march 2010) upstream zlib has incorporated back
the changes in minizip 1.1 (and in zlib124 package) in a cleaner & backward
compatible way by adding new symbols with 64 prefix. So if latest minizip was
a dependency, we could drop the cpl_minizip files from GDAL source and use
upstream version instead. The ZIP64 issue isn't terribly important to me so
this would certainly not be a show-stopper for moving to another solution
that would only require using the old minizip interfaces. And the
cpl_vsil_gzip.cpp code could certainly be adapted to work with classic or
zip64 symbols according to what is available.


I've took a crack to add minizip support to the Windows buildslaves and switch this new driver on, I hope the next build will compile this driver in the plugins section.

However the desired compilation flags of minizip are not so trivial to me, is the ZIP64 support enabled by default, should I define further variables?
Do we expect to compile minizip as a library or a dll package? The latter seems to be controlled by ZEXPORT which is not defined properly on Windows. (zlib is using explicit definition of the exported functions by using a .def file and not by __declspec(dllexport))

Do we have auto-tests included along with this driver in order to make sure the compilation is working?

Best regards,


Tamas