[Zlib-devel] Testing CMakeLists from zlib 1.2.3.5

[Philip Lowman]

On Tue, Jan 12, 2010 at 11:28 PM, Cosmin Truta <ctruta at gmail.com> wrote:
> Hello, Mark,
>
> I tried the cmakefile that Philip provided (thanks, Philip!), and it
> creates the Visual C++ project just fine.
> However, when building zlib using the auto-generated project, I get
> the following warnings+errors:
>
> gzwrite.c(136) : warning C4018: '<' : signed/unsigned mismatch
> gzwrite.c(195) : error C2036: 'voidpc' : unknown size
> gzread.c(335) : warning C4018: '>' : signed/unsigned mismatch
> gzread.c(425) : error C2036: 'voidp' : unknown size
> gzlib.c(330) : warning C4018: '>' : signed/unsigned mismatch

Cosmin,

I hadn't gotten around to testing 1.2.3.5 yet so thanks for doing
that.  gzwrite.c and gzread.c look to be new source files not in
1.2.3.4 and VS is having a problem because it doesn't know the size of
the void* ?!?

This is a VS issue and not due to anything different I'm doing in
CMakeLists.txt, the VC6 projects that come bundled in the projects/
directory cause the same build error.

> 1). Is the cmakefile not designed to build both the static and the
> shared lib? As far as I could see, it's only creating makefiles for
> shared lib builds.

You can toggle the BUILD_SHARED_LIBS option in cmake-gui if you want
static.  I considered building both simultaneously but users would
likely complain about which import library name gets "zlib.lib".

> 2). Setting the target properties (zlib PROPERTIES DEFINE_SYMBOL
> ZLIB_DLL) should be done when building the shared DLL library. (It's
> not required, though.) But when building the static zlib.lib, that
> property must not be set.

CMake only defines the DEFINE_SYMBOL property when building a shared
library target.  The line you mentioned above is in the 1.2.3.5
CMakeLists.txt.

> 3). zlib's DLL name is zlib1.dll, the same was as libpng's DLL name is
> libpng14.dll. See the DLL_FAQ.txt in the win32/ directory.

Thanks, didn't realize this.  I will fix the output name of the DLL to
be zlib1.dll in a future patch.  I believe this is done with the
OUTPUT_NAME CMake target property.

> 4). Is it necessary to hard-code the zlib version (zlib PROPERTIES
> VERSION 1.2.3.4)? It's an extra maintenance issue, and one more thing
> to fall out of sync. (As you see, it did already.)

I will add support to read the version number from zlib.h dynamically.
 I also never tested to see if the VERSION property in CMakeLists.txt
is actually doing anything to the DLL so I'll do that as well.

> 5). Small suggestion: perhaps make CMAKE_DEBUG_POSTFIX lowercase "d"?
> IMO, the output library file name zlib1d.dll looks better than
> zlib1D.dll.

Good idea, I will also make this change.

-- 
Philip Lowman