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

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'.

Bob Rossi