GTest & MSVC woes

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download r2677
2. Compile and build with MSVC x64 (I'm using 2012)
3. Compilation breaks on gtest-all.cc (namely in the tuple section)

Basically gtest sucks as determining whether the system has a tuple 
implementation present.  

Currently we test if there is a system implementation of tuple by trying:

#include <tr1/tuple>

However, this fails when using cl, as the correct syntax would be:  

#include <tuple>

_______________________
The result of this test is stored in the 'HAS_TR1_TUPLE' variable.  

In the ext/SConstruct file, we use:  

if not localenv['HAS_TR1_TUPLE']:
    localenv.Append(CPPDEFINES='GTEST_USE_OWN_TR1_TUPLE')

to define 'GTEST_USE_OWN_TR1_TUPLE' (which then breaks on the gtest-all.cc 
compile).
________________________

The only way I've been able to get the newest release to compile on Windows is 
to comment those lines in ext/SConstruct out.  

Things I've also tried:  

adding a /DGTEST_USE_OWN_TR1_TUPLE=0 to the CXX_FLAGS (I think it gets canceled 
out by the /DGTEST_USE_OWN_TR1_TUPLE thats appended as a result of the 
SConstruct file)

adding a /I"Path to boost folder" the CXX_FLAGS (to try and get CL to pick up 
the tr1/tuple.hpp file in the boost libraries).  I would guess this failed due 
to the VS Command Prompt's paths?  Not really sure, I thought it would work.
__________________________

I suggest we modify the tuple test to #include <tuple> if we're on Windows and 
using MSVC.  I'm not sure how we'd do that (fuzzy on my SCons)

Nick Curtis

Original issue reported on code.google.com by argh...@gmail.com on 20 Jan 2014 at 7:44

[GoogleCodeExporter]

Actually, I fixed it as easily as changing:

env['HAS_TR1_TUPLE'] = conf.CheckCXXHeader('tr1/tuple', '<>') 

to:

env['HAS_TR1_TUPLE'] = conf.CheckCXXHeader('tr1/tuple', '<>') or 
conf.CheckCXXHeader('tuple', '<>')

The cleanest way would probably be:

if (os.name == 'nt' and msvc_version != None):
    env['HAS_TR1_TUPLE'] = conf.CheckCXXHeader('tuple', '<>')
else:
    env['HAS_TR1_TUPLE'] = conf.CheckCXXHeader('tr1/tuple', '<>')

Nick

Original comment by argh...@gmail.com on 20 Jan 2014 at 8:02

[GoogleCodeExporter]

Can you try updating gtest to the most recent version (1.7)? The changelog says 
that it  has "Compatibility fixes with C++ 11 and various platforms", which may 
resolve this problem (and if we're lucky, not introduce any new ones).

The conditions for which this happens are more specific than just Windows+MSVC. 
Gtest compiles fine when using VS2008, which is the version compatible with 
Python 2.7.

If we tell gtest to use it's own implementation of tr1/tuple, it doesn't make 
sense to me that it should matter what the path to an external implementation 
of tuple is. Can you post the full text of the error you get, if updating gtest 
doesn't fix it?

Original comment by yarmond on 21 Jan 2014 at 3:23

• Changed state: Accepted

[GoogleCodeExporter]

After updating gtest to 1.7.0 (r2680), this configuration check does not seem 
to be necessary on OS X (which is the platform that originally required it), so 
I've removed the check as of r2681.

Let me know if this resolves the problems with VS2012.

Original comment by yarmond on 21 Jan 2014 at 5:25

• Changed state: InProgress

[GoogleCodeExporter]

Ray, this resolved the problem with VS2012.

Thanks!
Nick

Original comment by argh...@gmail.com on 21 Jan 2014 at 8:25

[GoogleCodeExporter]

Original comment by yarmond on 21 Jan 2014 at 8:27

• Changed state: Fixed

[GoogleCodeExporter]

Oh, and as far as VS2012 not being compatible with python 2.7, all you have to 
do is redirect/add the environment variable VS90COMNTOOLS to point to the same 
path as VS110COMNTOOLS.  This might be an issue if you have multiple installs 
of visual studio, but it works just fine with just a 2012 install

Original comment by argh...@gmail.com on 21 Jan 2014 at 8:28