[CMake] CMake 2.8.4-rc1 ready for testing!

[Pau Garcia i Quiles]

On Thu, Jan 13, 2011 at 3:15 PM, David Cole <david.cole at kitware.com> wrote:
> I am happy to announce that CMake 2.8.4 has entered the release
> candidate stage! You can find the source and binaries here:
> http://www.cmake.org/files/v2.8/?C=M;O=D
>
> Following is the list of changes in this release. Please try this version
> of CMake on your projects and report any issues to the list or the
> bug tracker.
>
> Happy building!
>
> -Dave

A couple of issues I'd noticed:

- On Windows, FindZLIB.cmake is unable to find zlib if you built zlib
using CMake. Apparently the zlib's CMake buildsystem uses library
names different from the ones produced by other build methods.

- FindPNG.cmake does not support libpng 1.5

The attached path fixes both issues

One more thing I've noticed is ExternalProject_Add does not honor the
CMAKE_BUILD_TYPE. For instance, if I have this:

--8<----------------------------------
project( winst )

cmake_minimum_required(VERSION 2.8)

include (ExternalProject)
set(CMAKE_PREFIX_PATH ${PROJECT_SOURCE_DIR} )

#find_package( PNG REQUIRED )

ExternalProject_Add( zlib
    DOWNLOAD_DIR ${PROJECT_SOURCE_DIR}/downloads
    URL http://prdownloads.sourceforge.net/libpng/zlib125.zip
    PATCH_COMMAND ${CMAKE_COMMAND} -E remove zconf.h
    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${PROJECT_SOURCE_DIR}
-DCMAKE_PREFIX_PATH:PATH=${PROJECT_SOURCE_DIR}
    )
--8<----------------------------------

And I call CMake like "cmake -DCMAKE_BUILD_TYPE=Release", it will
build zlib in Debug. It's easily fixable by adding
"-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}" to the CMAKE_ARGS but I'd say
it violates the principle of least surprise.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-2.8.4-rc1.patch
Type: application/octet-stream
Size: 1123 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110114/b03e3289/attachment.obj>