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

Top Page
Delete this message
Author: Sheri
Date:  
To: pcre-dev
Subject: Re: [pcre-dev] Current state of cmake support
(sorry Christian, I keep forgetting to change my replies so they get
addressed to the group instead of the individual sender).
Sheri wrote:
> Christian Ehrlicher wrote:
>> Hi,
>>
>> Someone from the list asked me to join the list so I can help you
>> with some problems with pcre & cmake.
>> It's nice that you're interested in cmake support - I just added
>> basic support for cmake to compile it for kde4/windows but then lost
>> track because of various changes in the internal structure of pcre.
>>
> Thank you for coming Christian. Windows is pcre's step-child :) and
> needs more nurturing.
>> 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)
> Without zip support those are will not be popular on Windows.
>> Readline support needs some enhancements too (but cmake currently
>> does not provide a FindReadline.cmake - maybe we should use this from
>> kdeedu)
>> - 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
>>
> and for shared libraries built on other platforms on Windows. I need
> it for what I do, and I've been building with Msys/mingw.
>> - 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.
>>
>>
> Personally I really only have this one use for cmake and for Msys
> (i.e., building pcre libraries, and testing other components of the
> pcre distribution and build options), but I'm all for doing it easier
> if I can. What environment are you supposed to use for cmakesetup and
> make in, if not msys? DOS? What command do you use for making? I'm not
> currently set up with the proper enviroment to use mingw anywhere but
> Msys. I use the verbose makefile so I can grab the linking command
> from the console output for each library and reprocess it after the
> fact with .coff files. If you put .rc files in your source dir for
> MSVC builds, they get built and incorporated, but for Msys/mingw they
> have to be added.
>
> Anyway if there's another way to use cmake and mingw, we need to add a
> step-by-step in "NON-UNIX-USE" where building pcre with cmake is
> documented.
>
> Regards,
> Sheri
>
>