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

On Fri, Jan 18, 2008 at 11:02:36AM -0500, Sheri wrote:
> Christian Ehrlicher wrote:
> > Sheri schrieb:
> >
> >> Christian Ehrlicher wrote:
> >>
> >>>> Where are you heading on those prefixes? We need at least the option
> >>>> to make dlls in mingw and msys/mingw without "lib" prefix. All
> >>>> previous and current releases that included cmake build options did
> >>>> it for pcre and pcreposix without asking. (Problem was, it was also
> >>>> done for static libraries, and unix builds prior to latest). In my
> >>>> trial build with current revisions, it made libpcre.dll,
> >>>> libpcreposix.dll and libpcrecpp.dll.
> >>>>
> >>>>
> >>>>
> >>> Do you really need such an option? Why? It was wrong.
> >>> If you need it we can add an option explicit for mingw.
> >>>
> >>>
> >> Yes, sorry I really do. :)
> >>
> >>
> > Ok, I'll add an option for mingw only and mark it as 'advanced' to
> > restore backward compatibility.
> >
> >
> >
> 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