On Sun, 2007 Mar 25 07:21:49 -0400, Bob Rossi wrote:
>
> I'm not sure I agree here. If it's just a matter of running a few more
> commands, why not just do it? Also, what is really the difference
> between a autotools generated dll and a cmake generated dll?
You can put in that rule to generate pcre.dll, but then what about building
pcregrep.exe linked against that DLL? You have to sidestep the existing
rule that links against libpcre-0.dll. Effectively, you end up with a
hand-made mini-Makefile living inside the Automake-generated one, and not
coexisting very well.
The proper place to handle this would be Libtool---where it builds
libpcre.la, but actually dumps pcre.dll under .libs (or _libs). I don't
have experience with it running under Cygwin/MinGW to know how to do this,
however, or if this is even possible.
We could assemble a small, hand-built Makefile containing all the
appropriate linking rules (e.g. "Makefile.mingw"). But the reason I'm
saying "just use CMake" is that we're using CMake precisely to avoid the
need to maintain different sets of build definitions for non-POSIX (and
quasi-POSIX) build environments in the first place.
As it is, the intent here is evidently to build a Windows-native PCRE DLL,
without using the Microsoft toolchain or SDK. The end result is not
appreciably different from building pcre.dll using Visual Studio; only the
means of getting there. It seems reasonable to me to support the first in
the same manner as the second.
(In practical terms, too, I'd like the Visual Studio users to benefit from
the .coff metadata thingy as well, without duplicating effort.)
--Daniel
--
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = skunk@??? ## don't smell bad--- (/o|o\) /
EMAIL2 = skunk@??? ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
