[Zlib-devel] zlib version 1.2.3.8 available for testing

Philip Lowman philip at yhbt.com
Mon Feb 15 22:32:39 EST 2010


On Mon, Feb 15, 2010 at 2:27 AM, Mark Adler <madler at alumni.caltech.edu> wrote:
> Philip,
>
> Is CMake supposed to replace the functionality of configure and make combined?  If so, then there are other things that need to be done, like modifying zconf.h to not depend on HAVE_UNISTD_H when installed and used as a library header.  That's why configure replaces #ifdef HAVE_UNISTD_H with #if 1.

CMake isn't a make replacement.  It replaces the functionality of
autoconf & automake by generating Makefile equivalents for GNU Make
and NMake as well as Visual Studio Solution and XCode files that you
can open with a GUI (along with other IDEs like Eclipse, KDevelop, and
Codeblocks).

The patch I submitted results in "#define HAVE_UNISTD_H" being added
to the autogenerated zconf.h when CMake detects unistd.h as a system
include.  So the net effect is as if you replaced #ifdef HAVE_UNISTD_H
with #if 1, the only difference is HAVE_UNISTD_H will be declared for
anyone that #includes zlib.h.  I'm not sure if this is a big deal or
not... my guess is probably it's fine?  If not, the easiest way to fix
it from my point of view would be to use a ZLIB specific #define
instead, like ZLIB_HAVE_UNISTD_H or something like that.  Then I can
do something that makes much more sense to autoconf & CMake users
alike, like this:

#define ZLIB_HAVE_UNISTD_H @HAVE_UNISTD_H@
...
later in file
#ifdef ZLIB_HAVE_UNISTD_H
   #include <unistd.h>
   etc.
#endif

P.S.

If zconf.h is going away for sure from the tarball, I have a further
improvement I'd like to make to the CMake build so that we don't have
to clutter up the source tree with zconf.h.  It's considered bad
practice to modify the source tree with CMake builds as users get used
to out-of-source builds quickly and relying on multiple build
directories for all of their various platforms all pointing back to a
single source directory.  A change like the one below would prevent
someone from running ./configure and then later switching to a CMake
out-of-source build and the code subsequently picking up the stale
zconf.h in the source directory instead of the autogenerated zconf.h
in the build directory.

===
if(NOT CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR)
   # If we're doing an out of source build and the user has a zconf.h
   # in their source tree...
   if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/zconf.h)
      message(FATAL_ERROR "You must remove zconf.h from the source tree.  This f
ile is generated by the ./configure script shipped with zlib.  CMake generates t
his file for you automatically in the build directory")
   endif()
endif()

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/zconf.h.in
               ${CMAKE_CURRENT_BINARY_DIR}/zconf.h @ONLY)
include_directories(${CMAKE_CURRENT_BINARY_DIR})

-- 
Philip Lowman




More information about the Zlib-devel mailing list