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

Bob Rossi schrieb:
> On Fri, Jan 18, 2008 at 11:17:48AM -0500, Sheri wrote:
>> Bob Rossi wrote:
>>>> Would it make sense and also be possible to add similar options for
>>>> "suffix"?
>>>>
>>>> If I use configure & make (in Msys/mingw), electing shared libraries I
>>>> get pcre-0.dll, pcreposix-0.dll and pcrecpp-0.dll. But electing static
>>>> libraries, I get pcre.a, pcreposix.a and pcrecpp.a. Possibly someone
>>>> making the switch to cmake might like to maintain filename suffix
>>>> compatibility. I don't know if this is only applicable in mingw or not.
>>>> Philip, are name suffixes consistent between Configure and make vs cmake
>>>> built shared and static libraries on Linux?
>>>>
>>> We can remove the -0 from the shared libraries if you would like with
>>> the autotools build system. So instead of
>>> pcre-0.dll, we could have pcre.dll.
>>>
>>> Does this matter to you? I thought perhaps the versioning could be
>>> helpful, but, I'm not sure.
>>>
>>> Thanks,
>>> Bob Rossi
>>>
>>>
>>>
>> Welcome back Bob. Sorry for creating confusion here, I mispoke.
>> Autotools is producing libpcre-0.dll, etc. (shared) and libpcre.a, etc.
>> (static). I also mispoke in another earlier note. The support for
>> alternate library names previously added to our particular app was for
>> libpcre-0.dll, etc. names (not libpcre.dll). So no, I don't think it
>> should be changed at this stage of the game. I just think the (mingw)
>> library naming options in cmake should be flexible enough for the
>> variety of backward compatibility situations users might encounter.
>
> It's good to be back. :)
>
> OK, just to be clear, it's possible to have the mingw version just put
> out 'pcre.dll' instead of libpcre-0.dll'.
>
MinGW libs should be named libfoo.dll and if it's just to make the
linker happy - When the linker finds -lfoo it looking for libfoo.a/.dll
an if it doesn't find it, it tries numerous other things afaik.
If you want a '-0' somwhere, we've to add it explicit. But this is just
needed in cases of binary incompatible changes to not use the wrong lib.
Another point why we should append 'lib' is to not get in conflict with
the msvc library. You can't mix msvc and mingw libraries when you e.g.
pass a FILE* pointer or it's a c++ lib.

I've attached a new version. This time with readline support (thx. to
kdeedu). As you can see there's a new subidr 'cmake' where
FindReadline.cmake is located - if you don't like it we can move it
around to a place of you desire.

It still does not contain the mingw-backward compatibility hack.


Christian