(Sorry Bob, I forgot to change to the group address on an earlier send
of this message..)
Bob Rossi wrote:
> On Sun, Mar 25, 2007 at 02:54:02AM -0400, Daniel Richard G. wrote:
>
>>> # Some Windows-specific targets for MinGW. Do not use for Cygwin.
>>>
>>> winshared : .libs/@WIN_PREFIX@??? .libs/@WIN_PREFIX@??? \
>>> .libs/@WIN_PREFIX@???
>>>
>>> .libs/@WIN_PREFIX@??? : libpcre.la
>>> $(CC) $(CFLAGS) -shared -o $@ pcre.coff\
>>> -Wl,--whole-archive .libs/libpcre.a \
>>> -Wl,--out-implib,.libs/libpcre.dll.a \
>>>
>> [...]
>>
>> I'm thinking that all this---the rules to create e.g. pcre.dll, and the
>> .coff metadata---should be addressed by the CMake side of things. They're a
>> bit of a third wheel in Makefile.am, and MinGW can be considered a special
>> case of a "Windows build environment."
>>
>> This way, on MinGW, ./configure gets you Unixy-style MinGW libraries
>> (libpcre-0.dll et al.), and CMake gets you more Windowsy-style ones
>> (pcre.dll + Explorer properties).
>>
>
> 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?
>
> Bob Rossi
>
>
I myself installed and learned Msys/MinGW for the sole purpose of using
configure to make pcre libraries. It seems ironic that because it was
MinGW, it was formerly doing something "bad". :(
While I look forward to trying to build with cmake, at present I don't
know even the first thing about it. I just googled it and learned that
some projects have abandoned autoconf in favor or cmake. So while I was
under the impression from this discussion that cmake was a Windows
thingy, it is evidently an alternative multiplatform thingy.
PCRE is simultaneously embracing both autoconf *and* cmake ?
The 7.1RC2 windows dlls produced by configure are a bit larger (not
outrageously so) than their 7.0 counterparts. Don't know if the libtool
business can be optimizied or something.
I think it should still be possible for me to incorporate the coff file
somewhere, it is a MinGW binary file that needs to be included for linking.
My initial reaction is, I don't think two different sets of Windows
names getting produced by alternate processes (configure and cmake)
would be desirable; the libraries built should be interchangeable IMO.
If the unixy file names are a must, then IMO the cmake process should
use them too.
The problem with "new" names is, a lot of Windows software dependent on
shared libraries would need to be recompiled (at a minimum) to upgrade.
Daniel Richard G. is saying that for Windows users to have an option to
maintain the status quo on file names, they would need to implement
cmake. I think it would be nicer to recommend that everyone start using
cmake, without initially forcing it on anyone.
Regards,
Sheri
