There are two categories of GTEST_HAS_* macros:
1. those indicating the properties of the environment in which gtest is used:
39: // The user can define the following macros in the build script to
40: // control Google Test's behavior. If the user doesn't define a macro
41: // in this list, Google Test will define it.
2. those indicating the availability of gtest features:
113: // Macros indicating available Google Test features (defined to 1 if
114: // the corresponding feature is supported; otherwise undefined):
In gtest's model, a user is allowed to define a macro in #1, but #2 is
considered read-only to the user: gtest defines them based on whether
it's feasible to implement the features in the current environment --
the user cannot dictate that.
It's unfortunate that the two kinds of macros follow the same naming
convention, as this has created confusion several times in the past.
Perhaps we should adopt different naming conventions for them, e.g. use
GTEST_PROVIDES_FOO to indicate that gtest implements the FOO feature, while
still using GTEST_HAS_BAR to indicate that gtest is used in an environment that
has the BAR resource:
GTEST_HAS_STD_WSTRING
vs
GTEST_PROVIDES_DEATH_TESTS
This will affect existing clients that depend on macros in #2. I don't expect
there to be many clients though, and the fix is easy.
Original issue reported on code.google.com by w...@google.com on 20 Mar 2011 at 3:59
Original issue reported on code.google.com by
w...@google.comon 20 Mar 2011 at 3:59