Currently the googletest internal tests build after the matching library.
However, each of these is serialized at the top level makefile.
Additionally some of the tests (e.g. the gmock-matches-test) take up to
90 seconds to build with clang -O2. Having to wait for this test to
complete before continuing to the next directory seriously slows down the
parllelism of a -j32 build.
Before this change running `make -C lib/googletest -j32 -s` in buildenv
took 202 seconds, now it's 153 due to improved parallelism.
Reviewed By: emaste (no objection)
Differential Revision: https://reviews.freebsd.org/D26748
Per the upstream pull-request [1]:
```
gtest prior to this change would completely ignore `GTEST_SKIP()` if
called in `Environment::SetUp()`, instead of bailing out early, unlike
`Test::SetUp()`, which would cause the tests themselves to be skipped.
The only way (prior to this change) to skip the tests would be to
trigger a fatal error via `GTEST_FAIL()`.
Desirable behavior, in this case, when dealing with
`Environment::SetUp()` is to check for prerequisites on a system
(example, kernel supports a particular featureset, e.g., capsicum), and
skip the tests. The alternatives prior to this change would be
undesirable:
- Failing sends the wrong message to the test user, as the result of the
tests is indeterminate, not failed.
- Having to add per-test class abstractions that override `SetUp()` to
test for the capsicum feature set, then skip all of the tests in their
respective SetUp fixtures, would be a lot of human and computational
work; checking for the feature would need to be done for all of the
tests, instead of once for all of the tests.
For those reasons, making `Environment::SetUp()` handle `GTEST_SKIP()`,
by not executing the testcases, is the most desirable solution.
In order to properly diagnose what happened when running the tests if
they are skipped, print out the diagnostics in an ad hoc manner.
Update the documentation to note this change and integrate a new test,
gtest_skip_in_environment_setup_test, into the test suite.
This change addresses #2189.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
```
The goal with my merging in this change is to avoid requiring extensive
refactoring/retesting of test suites when ensuring prerequisites are met,
e.g., checking for a CAPABILITIES-enabled kernel before running capsicum-test
(see D19758 for more details).
The proof-of-concept is being imported before accepted by the upstream
project due to the fact that the upstream project is undergoing a potential
development freeze and the maintainers aren't responding to my PR.
1. https://github.com/google/googletest/pull/2203
Reported by: asomers (https://github.com/google/googletest/issues/2189)
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19765
This commit backports revisions 00938b2b228f3b70d3d9e51f29a1505bdad43f1e and
59f90a338bce2376b540ee239cf4e269bf6d68ad from googletest's master branch to
our included version of googletest, which is based on 1.8.1. It adds the
GTEST_SKIP feature, which is very useful for a project like FreeBSD where
some tests depend on particular system configurations.
Reviewed by: ngie
Obtained from: github.com/google/googletest
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/rS345331
The key difference is that some of the programs were previously being compiled
and installed as tests, which is incorrect. Treat them like helpers instead.
The former is from googletest.test.mk, whereas the latter is from plain.test.mk.
As noted in r344328, Kyua will adopt more native GoogleTest support. Thus, it's
more desirable to make the test interface more of an opaque blackbox for the
testcase implementer.
- Look up the corresponding non-*_main libraries via LDFLAGS using the
directories provided in src.libnames.mk. This will allow the libraries to
be built in the "make libraries" phase of buildworld.
- gtest_main relies on gtest, but didn't explicitly call out the dependency
in `LIBADD`. Fill in this missing blank.
