Re: [pcre-dev] Building with Msys/MinGW on Windows (was Re: …

On Sun, Mar 25, 2007 at 12:06:43PM -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". :(

pcre used to have a hand written Makefile, which was used to compile it.
The author of pcre had crafted this over many years, and people with
various different platform would send in patches to get pcre to build
there.

I wanted to build pcre on windows with Msys/Mingw, and realized it did
not build there. So I offered to rewrite the build system with the
Gnu autotools (autoconf, automake, ..).

So, the upcoming release of pcre should work out of the box on mingw.
It should be no different than any other platform.

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

Sure, cmake is I guess a competitor to the Gnu autotools build system.
I don't know much about it, however, I prefer the autotools build system
since it is used by many projects.

> PCRE is simultaneously embracing both autoconf *and* cmake ?

Yes, it is now. The autotools build system is mostly done, and the cmake
build system has not yet been done yet.

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

That's possible, does it matter?

> 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'm sorry, I simply haven't had time to look at this. I think we would
be glad to add this feature for you to the autotools build system.

If you want this feature, I suggest you build pcre. Tell us what options
you used for configure and make. Then, also tell us the exact commands
you need to run to get the functionality that you desire. Attach all of
the files that are required to do this.

That way, we can try this locally, and see if we should modify pcre's
build system and determine what new files should be distributed.

Sorry for asking again, I'm not very familiar with what people did with
the last release of pcre. Did this all work in pcre-7.0? Or did you have
to manually do this?

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

I sort of agree with this. I don't know what the convention for most
projects are though.

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

Yeah, I agree. I for one see cmake as an option. I don't ever plan on
using it. The autotools approach works for me, and others I believe will
feel the same for one or the other.

Thanks,
Bob Rossi