Re: [pcre-dev] Current state of cmake support

On Thu, 17 Jan 2008, Christian Ehrlicher wrote:

> Someone from the list asked me to join the list so I can help you with
> some problems with pcre & cmake.

Thank you. The list needs a CMake expert. :-)

> Here are some answers:
> - someone complains about absolute paths in Makefiles: That's how it needs to be. There's no reason to not use absolute paths at all. If you want to have more arguments against absolute paths, search the cmake mailing list
> - libbz2 and libz support is somewhat buggy - I fixed them the way it should be (so it's also platform independent) Readline support needs some enhancements too (but cmake currently does not provide a FindReadline.cmake - maybe we should use this from kdeedu)

That's because I hacked it in, not really knowing what I was doing. I'm
glad to hear it's been fixed properly.

> - the static linking problem is because the linker is searching for libpcreposix.a / libpcreposix.dll --> SET_TARGET_PROPERTIES(pcre pcreposix PROPERTIES PREFIX "") should only be used for MSVC
> - pcredemo - added
> - dftables - fixed, added option
> - cmake defines not much HAVE_foo_H. This is due the stupidness of automake's autoheader tool. It just adds HAVE_foo_H for cases where it's not needed just because it's not used anywhere inside the sourcecode.
> - some windows defines are missing - that's because they were added after 7.0
> - the use of msys - I don't know why someone would use msys when cmake can produce native mingw makefiles. Therefore I don't care much.
>
> The attached CMakeLists.txt is not tested on windows - will do this later today.

Thank you. I've saved it and will commit a patch when you confirm that
it's OK on Windows.

Philip

--
Philip Hazel