Closed GoogleCodeExporter closed 9 years ago
I can build and run msvc/gtest_unittest.vcproj without a problem, using VS 7.1.
That
test covers EXPECT_ANY_THROW. Can you try that?
I suspect that some setting in your project file triggered a bug in VC++ 7.1.
Before reporting an issue/bug, please send a report to the discussion group
such that
more people can read about it and help you.
Original comment by zhanyong...@gmail.com
on 16 Jan 2009 at 6:51
I can build msvc/gtest_unittest.vcproj without a problem, too.
What I can't do (aside from getting my own unit test to compile) is to add a
simple
EXPECT_ANY_THROW() macro test to any one of the samples, such as
sample1_unittest.cc.
When I do that and try to build I see the same compilation failure.
I'm not sure building gtest_unittest.cc is a fair test since it #includes some
of the
gtest internals, which a normal unit test shouldn't be doing.
I'll take your suggestion about the forums if there's a next time I encounter a
problem. Thanks for that.
Original comment by brodeur....@gmail.com
on 16 Jan 2009 at 8:11
[deleted comment]
Apparently there's something about Debug configurations that is triggering the
problem. If I create a new Win32 console application project (empty) using the
VS
2003.NET New Project Wizard, then add a single test containing
EXPECT_ANY_THROW() it
will compile correctly using the Release configuration but not the Debug
Configuration, which still has the errors above.
Original comment by brodeur....@gmail.com
on 22 Jan 2009 at 8:51
I believe this is a VC++ bug. Unfortunately it's unclear how we can work
around it
in gtest. IIRC, you can change the debug info database (.pdb) format you use
in the
Debug configuration to make the error go away. Please let me know if that
works.
Original comment by zhanyong...@gmail.com
on 22 Feb 2009 at 5:40
Yes, I think that you are right. If I change the "Debug Information Format"
from /ZI
(Program Database for Edit & Continue) to /Zi (Program Database) then the files
compile successfully. This is a perfectly fine resolution as far as I'm
concerned.
Thanks for looking at it.
Original comment by brodeur....@gmail.com
on 25 Feb 2009 at 6:28
Original comment by zhanyong...@gmail.com
on 23 Mar 2009 at 8:04
Original issue reported on code.google.com by
brodeur....@gmail.com
on 19 Dec 2008 at 3:51