On Sun, 2007 Mar 25 12:10:58 -0400, Sheri wrote:
>
> 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". :(
Not "bad," just a little off the beaten path :-)
> 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.
That's the idea. We decided on this as a better alternative to maintaining
project files for various IDEs and the like.
> PCRE is simultaneously embracing both autoconf *and* cmake ?
Yes, with the notion that Autotools would be used on POSIX platforms, and
CMake in most other places. (Virtual Pascal and such continue to be oddball
cases.)
> 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'd chalk it up to all the extra pedantry Libtool brings in. I don't think
this should be a concern, unless the library interface is negatively
affected.
> 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.
I think that is doable.
> 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 differing names are largely a result of the differing environments
presumed by the Autotools and CMake build systems: a POSIX system by the
former, a nonstandard entity by the latter. The Unixy names, concretely,
are dictated to us by Libtool; in theory, we should be able to tell Libtool
to drop the "lib" prefix and version-number suffix---but I don't know how
well that works in practice.
Incidentally, if you look under /usr/lib/ in the MinGW/MSYS filesystem, do
you see libraries more like foo.dll or libfoo-1.dll?
> 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.
The names everyone uses should certainly stay as "pcre.dll" and the like.
As for getting there... using Autotools would be more convenient for
Unix-experienced users with MinGW installed, true. But I suspect most
Windows users who want to build a PCRE DLL would either use Visual Studio,
or the free Microsoft compiler. And if the build tool addressing both those
cases (CMake) can support MinGW as well, then, well, everybody's covered :)
As for the "thou shalt use CMake" angle... ve've already said that this is
an acceptable cost for providing what amounts to perfect support for nearly
every popular IDE out there. The fact that KDE is using it gives us a lot
of cover, and the existence of the polished Windows GUI makes the
experience fairly painless for the Unix/CLI-phobic crowd.
--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)
