Port gtest to MinGW.

It didn't take much to make gtest compile on MinGW:

* Code using SEH doesn't work on MinGW, so I had to update the #ifdefs appropriately.  (No version of GCC supports SEH so I used defined(__GNUC__) as the condition.)

* MinGW defines helpful macros for posix functions which normally require a leading underscore on Windows.  Unfortunately this is totally incompatible with gtest's attempt to move these functions into a namespace.  For now I #undef'd them but this isn't a good long-term solution.

** UPDATE:  I reverted this part of the change as Zhanyong is working on a better fix.

* MinGW doesn't support pthreads.  The makefiles appear to assume that all systems use pthreads.  I went ahead and added the ACX_PTHREAD macro that several other Google open source projects use to the m4 directory and made the configure script use it to detect pthreads.  This should have other positive effects, like handling systems where the "-pthread" compiler flag doesn't exist (but -lpthread works).

[Zhanyong Wan, 2009-04-22 06:12:18]

Thanks for the contribution.  I'll leave the autotools stuff to an expert. 
Chandler and Benoit, would one of you be able to review the autotools part of
this patch?  Thanks!

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode739
Line 739: //   is #included in user code, and users might rely on these macros. 
We need
Exactly.  #undefining them in the general Windows code path is dangerous.  We
shouldn't check this in.

http://codereview.appspot.com/49041/diff/1/3#newcode740
Line 740: //   to either: (a) use completely different function names here, or
(b) use
I think we should do (a).  I can create a patch unless you want to do it.

http://codereview.appspot.com/49041/diff/1/2
File m4/acx_pthread.m4 (right):

http://codereview.appspot.com/49041/diff/1/2#newcode1
Line 1: # This was retrieved from
Any license issue with using this?

http://codereview.appspot.com/49041/diff/1/4
File src/gtest.cc (right):

http://codereview.appspot.com/49041/diff/1/4#newcode2016
Line 2016: #if GTEST_OS_WINDOWS && !defined(__GNUC__)
I think __try is an MS extension.  Therefore shouldn't we say "#ifdef _MSC_VER"
here?

http://codereview.appspot.com/49041/diff/1/4#newcode2256
Line 2256: #if GTEST_OS_WINDOWS && !defined(__GNUC__)
The same.

http://codereview.appspot.com/49041/diff/1/4#newcode3333
Line 3333: #if GTEST_OS_WINDOWS && !defined(__GNUC__)
The same.

[tsuna, 2009-04-22 07:34:39]

LGTM

http://codereview.appspot.com/49041/diff/1/5
File configure.ac (right):

http://codereview.appspot.com/49041/diff/1/5#newcode1
Line 1: m4_include(m4/acx_pthread.m4)
This shouldn't be required.  I have a pending patch in my git repository to
address this.  I'll send it out for review today.

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode740
Line 740: //   to either: (a) use completely different function names here, or
(b) use
On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> I think we should do (a).  I can create a patch unless you want to do it.

I second this.

[Vlad, 2009-04-22 07:41:41]

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
Should use HAVE_PTHREAD set by the autotools script here.

http://codereview.appspot.com/49041/diff/1/4
File src/gtest.cc (right):

http://codereview.appspot.com/49041/diff/1/4#newcode2016
Line 2016: #if GTEST_OS_WINDOWS && !defined(__GNUC__)
On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> I think __try is an MS extension.  Therefore shouldn't we say "#ifdef
_MSC_VER"
> here?

I think a better solution will be to define a macro GTEST_HAS_SEH in
gtest-port.h and then use it here. Some other compilers may also implement SEH
support and we won't have to make changes in multiple places if we encounter
some of them.

Plus, it's more readable. :-)

[kenton, 2009-04-23 21:35:02]

Patch updated.

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
On 2009/04/22 07:41:41, Vlad wrote:
> Should use HAVE_PTHREAD set by the autotools script here.

We can't, because this is an installed header and config.h is not an installed
header.

http://codereview.appspot.com/49041/diff/1/3#newcode740
Line 740: //   to either: (a) use completely different function names here, or
(b) use
On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> I think we should do (a).  I can create a patch unless you want to do it.

I've reverted this part of my patch in favor of your change.

http://codereview.appspot.com/49041/diff/1/2
File m4/acx_pthread.m4 (right):

http://codereview.appspot.com/49041/diff/1/2#newcode1
Line 1: # This was retrieved from
On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> Any license issue with using this?

No.

http://codereview.appspot.com/49041/diff/1/4
File src/gtest.cc (right):

http://codereview.appspot.com/49041/diff/1/4#newcode2016
Line 2016: #if GTEST_OS_WINDOWS && !defined(__GNUC__)
On 2009/04/22 07:41:41, Vlad wrote:
> On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> > I think __try is an MS extension.  Therefore shouldn't we say "#ifdef
> _MSC_VER"
> > here?
> 
> I think a better solution will be to define a macro GTEST_HAS_SEH in
> gtest-port.h and then use it here. Some other compilers may also implement SEH
> support and we won't have to make changes in multiple places if we encounter
> some of them.
> 
> Plus, it's more readable. :-)

Done.

[Vlad, 2009-04-23 23:47:15]

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
On 2009/04/23 21:35:03, kenton wrote:
> On 2009/04/22 07:41:41, Vlad wrote:
> > Should use HAVE_PTHREAD set by the autotools script here.
> 
> We can't, because this is an installed header and config.h is not an installed
> header.

Is it possible to have -DHAVE_PTHREAD added to the compiler command line by the
autoconf script?

[kenton, 2009-04-24 00:40:08]

I've updated this patch to rev 242 which contains a proper fix for the POSIX
function/macro problem.  With that change everything once again works on MinGW.

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
On 2009/04/23 23:47:15, Vlad wrote:
> On 2009/04/23 21:35:03, kenton wrote:
> > On 2009/04/22 07:41:41, Vlad wrote:
> > > Should use HAVE_PTHREAD set by the autotools script here.
> > 
> > We can't, because this is an installed header and config.h is not an
installed
> > header.
> 
> Is it possible to have -DHAVE_PTHREAD added to the compiler command line by
the
> autoconf script?

No.  Since this is an installed header, you would have to tell all users to pass
that flag when compiling their own apps, which is unreasonable.

The only thing we can do here is avoid using GTEST_HAS_PTHREAD in installed
headers at all, and replace all private uses of GTEST_HAS_PTHREAD with the
autoconf-defined HAS_PTHREAD.  I'd rather not do this in my patch -- what I have
now is at least a strict improvement over what was there before.

[Vlad, 2009-04-24 01:35:46]

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
On 2009/04/24 00:40:09, kenton wrote:
> On 2009/04/23 23:47:15, Vlad wrote:
> > On 2009/04/23 21:35:03, kenton wrote:
> > > On 2009/04/22 07:41:41, Vlad wrote:
> > > > Should use HAVE_PTHREAD set by the autotools script here.
> > > 
> > > We can't, because this is an installed header and config.h is not an
> installed
> > > header.
> > 
> > Is it possible to have -DHAVE_PTHREAD added to the compiler command line by
> the
> > autoconf script?
> 
> No.  Since this is an installed header, you would have to tell all users to
pass
> that flag when compiling their own apps, which is unreasonable.
> 
> The only thing we can do here is avoid using GTEST_HAS_PTHREAD in installed
> headers at all, and replace all private uses of GTEST_HAS_PTHREAD with the
> autoconf-defined HAS_PTHREAD.  I'd rather not do this in my patch -- what I
have
> now is at least a strict improvement over what was there before.

I do not know autoconf well, so please bear with me here.
What prevents you from adding -DGTEST_HAS_PTHREAD=1 to PTHREAD_CFLAGS in
acx_pthread.m4 when the presence of pthreads is detected? Users' ability to
suppress use of pthreads should not be a concern since gtest doesn't use
pthreads itself; it is only used in some tests. But even with any possible
future use in mind, that define can be changed to something like
GTEST_HAS_PTHREAD_INTENAL_ and can be used by gtest-port.h to control
GTEST_HAS_PTHREAD when it's not defined by a user.

[Zhanyong Wan, 2009-04-24 17:51:01]

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
On 2009/04/24 01:35:46, Vlad wrote:
> On 2009/04/24 00:40:09, kenton wrote:
> > On 2009/04/23 23:47:15, Vlad wrote:
> > > On 2009/04/23 21:35:03, kenton wrote:
> > > > On 2009/04/22 07:41:41, Vlad wrote:
> > > > > Should use HAVE_PTHREAD set by the autotools script here.
> > > > 
> > > > We can't, because this is an installed header and config.h is not an
> > installed
> > > > header.
> > > 
> > > Is it possible to have -DHAVE_PTHREAD added to the compiler command line
by
> > the
> > > autoconf script?
> > 
> > No.  Since this is an installed header, you would have to tell all users to
> pass
> > that flag when compiling their own apps, which is unreasonable.
> > 
> > The only thing we can do here is avoid using GTEST_HAS_PTHREAD in installed
> > headers at all, and replace all private uses of GTEST_HAS_PTHREAD with the
> > autoconf-defined HAS_PTHREAD.  I'd rather not do this in my patch -- what I
> have
> > now is at least a strict improvement over what was there before.
> 
> I do not know autoconf well, so please bear with me here.
> What prevents you from adding -DGTEST_HAS_PTHREAD=1 to PTHREAD_CFLAGS in
> acx_pthread.m4 when the presence of pthreads is detected? Users' ability to
> suppress use of pthreads should not be a concern since gtest doesn't use
> pthreads itself; it is only used in some tests. But even with any possible
> future use in mind, that define can be changed to something like
> GTEST_HAS_PTHREAD_INTENAL_ and can be used by gtest-port.h to control
> GTEST_HAS_PTHREAD when it's not defined by a user.

Vlad, I think it's an interesting idea for gtest to get more information from
autotools.  OTOH, HAS_PTHREAD is not the only one that can benefit.  It's
cleaner to keep this patch simple, and do the autotools integration for all
capability macros in a separate patch.

http://codereview.appspot.com/49041/diff/1/2
File m4/acx_pthread.m4 (right):

http://codereview.appspot.com/49041/diff/1/2#newcode1
Line 1: # This was retrieved from
On 2009/04/23 21:35:03, kenton wrote:
> On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> > Any license issue with using this?
> 
> No.

Is it possible to include a copy of the license in this file?  Don't worry if
it's not easy.

http://codereview.appspot.com/49041/diff/18/23
File Makefile.am (right):

http://codereview.appspot.com/49041/diff/18/23#newcode66
Line 66: EXTRA_DIST += $(m4data_DATA)
Shouldn't we add the new file in m4 here?

http://codereview.appspot.com/49041/diff/18/20
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/18/20#newcode493
Line 493: #endif
// GTEST_HAS_SEH

http://codereview.appspot.com/49041/diff/18/19
File m4/acx_pthread.m4 (right):

http://codereview.appspot.com/49041/diff/18/19#newcode81
Line 81: AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with
CFLAGS=$PTHREAD_CFLAGS])
Nit: can we fit this in 80 columns?

http://codereview.appspot.com/49041/diff/18/19#newcode102
Line 102: acx_pthread_flags="pthreads none -Kthread -kthread lthread -pthread
-pthreads -mthreads pthread --thread-safe -mt pthread-config"
Ditto.

http://codereview.appspot.com/49041/diff/18/19#newcode156
Line 156: PTHREAD_LIBS="`pthread-config --ldflags` `pthread-config --libs`"
Ditto.

http://codereview.appspot.com/49041/diff/18/19#newcode271
Line 271: AC_MSG_CHECKING([whether to check for GCC pthread/shared
inconsistencies])
Ditto.

http://codereview.appspot.com/49041/diff/18/19#newcode337
Line 337: AC_MSG_WARN([Impossible to determine how to use pthreads with shared
libraries])
Ditto.

http://codereview.appspot.com/49041/diff/18/19#newcode356
Line 356: ifelse([$1],,AC_DEFINE(HAVE_PTHREAD,1,[Define if you have POSIX
threads libraries and header files.]),[$1])
Ditto.

[kenton, 2009-04-24 20:32:58]

Updated patch set 5.  (Ignore patch set 4 -- accidentally uploaded at the wrong
time, and apparently I can't delete it.)

http://codereview.appspot.com/49041/diff/1/3
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/1/3#newcode334
Line 334: #define GTEST_HAS_PTHREAD (GTEST_OS_LINUX || GTEST_OS_MAC)
On 2009/04/24 01:35:46, Vlad wrote:
> I do not know autoconf well, so please bear with me here.
> What prevents you from adding -DGTEST_HAS_PTHREAD=1 to PTHREAD_CFLAGS in
> acx_pthread.m4 when the presence of pthreads is detected?

Nothing.  But that won't help.

The point is that gtest-port.h is installed in /usr/include/gtest/internal, and
then is include *from user code*.  That user code is compiled in ways that we
cannot control.  We can't just tell all users to pass -DGTEST_HAS_PTHREAD=1 when
compiling their own code; this would be too much of a pain for users.

> Users' ability to
> suppress use of pthreads should not be a concern since gtest doesn't use
> pthreads itself; it is only used in some tests.

If that's the case, then we should be able to remove GTEST_HAS_PTHREAD from
gtest-port.h.  Have those tests check HAVE_PTHREAD from config.h instead.

http://codereview.appspot.com/49041/diff/1/2
File m4/acx_pthread.m4 (right):

http://codereview.appspot.com/49041/diff/1/2#newcode1
Line 1: # This was retrieved from
On 2009/04/24 17:51:02, Zhanyong Wan wrote:
> On 2009/04/23 21:35:03, kenton wrote:
> > On 2009/04/22 06:12:18, Zhanyong Wan wrote:
> > > Any license issue with using this?
> > 
> > No.
> 
> Is it possible to include a copy of the license in this file?  Don't worry if
> it's not easy.

Again, this file is included in lots of Google open source projects.  I agree
the license info should probably be clearer but I think the best thing to do is
talk to Craig Silverstein about updating the central copy, then propagate that
change to all the projects that use it.

http://codereview.appspot.com/49041/diff/18/23
File Makefile.am (right):

http://codereview.appspot.com/49041/diff/18/23#newcode66
Line 66: EXTRA_DIST += $(m4data_DATA)
On 2009/04/24 17:51:02, Zhanyong Wan wrote:
> Shouldn't we add the new file in m4 here?

Since it is included explicitly in configure.ac, autoconf already knows to
include it.  I tried running "make distcheck" to verify but it seems to fail for
other reasons unrelated to my change.  Checking the dist manually confirms that
acx_pthread.m4 is there.

http://codereview.appspot.com/49041/diff/18/20
File include/gtest/internal/gtest-port.h (right):

http://codereview.appspot.com/49041/diff/18/20#newcode493
Line 493: #endif
On 2009/04/24 17:51:02, Zhanyong Wan wrote:
> // GTEST_HAS_SEH

Done.

http://codereview.appspot.com/49041/diff/18/19
File m4/acx_pthread.m4 (right):

http://codereview.appspot.com/49041/diff/18/19#newcode81
Line 81: AC_MSG_CHECKING([for pthread_join in LIBS=$PTHREAD_LIBS with
CFLAGS=$PTHREAD_CFLAGS])
On 2009/04/24 17:51:02, Zhanyong Wan wrote:
> Nit: can we fit this in 80 columns?

I'd really prefer that any changes to this file be applied to the central copy,
otherwise the changes will just be clobbered the next time we update from there.

[Zhanyong Wan, 2009-04-24 20:59:17]

Looks good.  Thanks for the contribution, Kenton!