Describe the issue
The two GoogleMock Python tests, gmock_leak_test and gmock_output_test, are not registered with CTest in any CMake configuration, even when a Python 3 interpreter is present. Their C++ helper binaries are compiled, so the build spends time producing gmock_leak_test_ and gmock_output_test_, but nothing ever runs them.
This is a regression of #4124. That issue was fixed in February 2023 by fd36851, which stored the interpreter variables as CACHE INTERNAL so that they were visible outside the googletest directory scope. In June 2023, 812f35b replaced that code with find_package(Python3) and dropped the cache variables, and the tests silently stopped being registered again.
Both tests pass when invoked by hand against a normal CMake build, so this is purely a registration problem and not a problem with the tests themselves.
Steps to reproduce the problem
Configure with both test options enabled and count the registered tests:
cmake -S googletest -B build -Dgtest_build_tests=ON -Dgmock_build_tests=ON
ctest --test-dir build -N | tail -1
ctest --test-dir build -N | grep -E "gmock_leak_test|gmock_output_test"
Output:
The grep produces no output and exits with status 1: neither test is present.
Both tests pass when run manually against the same build tree:
$ PYTHONPATH=. python3 googlemock/test/gmock_output_test.py --build_dir=build/googlemock
Ran 1 test in 0.014s
OK
$ PYTHONPATH=. python3 googlemock/test/gmock_leak_test.py --build_dir=build/googlemock
Ran 5 tests in 0.013s
OK
For comparison, disabling Python entirely drops 18 tests, all of them googletest's:
cmake -S googletest -B build-nopython -Dgtest_build_tests=ON -Dgmock_build_tests=ON \
-DCMAKE_DISABLE_FIND_PACKAGE_Python3=ON
ctest --test-dir build-nopython -N | tail -1
63 minus 45 is 18, and every one of those 18 belongs to googletest. GoogleMock contributes zero Python tests in either case.
Root cause
find_package(Python3 COMPONENTS Interpreter QUIET) is called from googletest/cmake/internal_utils.cmake, which is included by googletest/CMakeLists.txt. When googlemock is built, it adds googletest as a subdirectory, so googletest's directory scope is a child of googlemock's. CMake functions are global, so py_test() is callable from googlemock/CMakeLists.txt, but the variable Python3_Interpreter_FOUND and the imported target Python3::Interpreter are both directory-scoped and do not propagate upward. py_test() therefore takes its early return every time it is called from googlemock.
A related consequence of the guard added in 8760db1: configuring with only -Dgmock_build_tests=ON, which is one of the commands suggested in CONTRIBUTING.md, skips the find_package call altogether.
Because find_package is QUIET and py_test() returns silently, there is no diagnostic in the configure output. A contributor who runs the documented build and sees CTest report success has no way to notice that two tests were never registered.
Suggested fix
Calling find_package(Python3 COMPONENTS Interpreter QUIET) inside if (gmock_build_tests) in googlemock/CMakeLists.txt, before the Python tests section, restores registration. Caching the variable as fd36851 did is no longer sufficient on its own, because py_test() now uses the imported Python3::Interpreter target, which is also directory-scoped.
A more conservative alternative, if adding the two tests to CI is not desirable right now, is to leave registration as it is and emit a message(STATUS ...) when the interpreter is not found, so that the silent skip at least becomes visible.
I am happy to send a pull request for either approach.
Scope
Not included, and can be filed separately if useful:
CONTRIBUTING.md still documents FindPythonInterp behaviour: it mentions the error message Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE) and suggests -DPYTHON_EXECUTABLE=path/to/python. With FindPython3 that variable is ignored; CMake reports Manually-specified variables were not used by the project: PYTHON_EXECUTABLE. The hint variable is now Python3_EXECUTABLE.ci/windows-presubmit.bat passes -DPYTHON_EXECUTABLE:FILEPATH=..., which is likewise no longer read.
Known limitation
Registering these tests puts them back into the official CI, which runs -Dgtest_build_tests=ON -Dgmock_build_tests=ON followed by ctest on both Linux and MSVC. gmock_output_test compares output against a golden file and has historically been sensitive to MSVC output differences: 0a3b403 fixed it for MSVC on the same day fd36851 enabled these tests, and 097f64e reverted that fix a week later. I have only been able to verify Linux, so the MSVC behaviour of the golden comparison is unknown to me and would need checking before merging.
What version of GoogleTest are you using?
0daf775 is the commit I reproduced on; git rev-parse --short HEAD reports 0daf775.
What operating system and version are you using?
Ubuntu 22.04.3 LTS, running under WSL2 on Windows.
What compiler and version are you using?
g++ 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3).
What build system are you using?
cmake version 3.22.1. Python 3.10.12 is present on PATH.
Additional context
The build currently compiles gmock_leak_test_ and gmock_output_test_ and then never runs them, so the cost of these tests is already being paid.
Describe the issue
The two GoogleMock Python tests,
gmock_leak_testandgmock_output_test, are not registered with CTest in any CMake configuration, even when a Python 3 interpreter is present. Their C++ helper binaries are compiled, so the build spends time producinggmock_leak_test_andgmock_output_test_, but nothing ever runs them.This is a regression of #4124. That issue was fixed in February 2023 by fd36851, which stored the interpreter variables as
CACHE INTERNALso that they were visible outside the googletest directory scope. In June 2023, 812f35b replaced that code withfind_package(Python3)and dropped the cache variables, and the tests silently stopped being registered again.Both tests pass when invoked by hand against a normal CMake build, so this is purely a registration problem and not a problem with the tests themselves.
Steps to reproduce the problem
Configure with both test options enabled and count the registered tests:
Output:
The
grepproduces no output and exits with status 1: neither test is present.Both tests pass when run manually against the same build tree:
For comparison, disabling Python entirely drops 18 tests, all of them googletest's:
63 minus 45 is 18, and every one of those 18 belongs to googletest. GoogleMock contributes zero Python tests in either case.
Root cause
find_package(Python3 COMPONENTS Interpreter QUIET)is called fromgoogletest/cmake/internal_utils.cmake, which is included bygoogletest/CMakeLists.txt. When googlemock is built, it adds googletest as a subdirectory, so googletest's directory scope is a child of googlemock's. CMake functions are global, sopy_test()is callable fromgooglemock/CMakeLists.txt, but the variablePython3_Interpreter_FOUNDand the imported targetPython3::Interpreterare both directory-scoped and do not propagate upward.py_test()therefore takes its early return every time it is called from googlemock.A related consequence of the guard added in 8760db1: configuring with only
-Dgmock_build_tests=ON, which is one of the commands suggested inCONTRIBUTING.md, skips thefind_packagecall altogether.Because
find_packageisQUIETandpy_test()returns silently, there is no diagnostic in the configure output. A contributor who runs the documented build and sees CTest report success has no way to notice that two tests were never registered.Suggested fix
Calling
find_package(Python3 COMPONENTS Interpreter QUIET)insideif (gmock_build_tests)ingooglemock/CMakeLists.txt, before the Python tests section, restores registration. Caching the variable as fd36851 did is no longer sufficient on its own, becausepy_test()now uses the importedPython3::Interpretertarget, which is also directory-scoped.A more conservative alternative, if adding the two tests to CI is not desirable right now, is to leave registration as it is and emit a
message(STATUS ...)when the interpreter is not found, so that the silent skip at least becomes visible.I am happy to send a pull request for either approach.
Scope
Not included, and can be filed separately if useful:
CONTRIBUTING.mdstill documentsFindPythonInterpbehaviour: it mentions the error messageCould NOT find PythonInterp (missing: PYTHON_EXECUTABLE)and suggests-DPYTHON_EXECUTABLE=path/to/python. WithFindPython3that variable is ignored; CMake reportsManually-specified variables were not used by the project: PYTHON_EXECUTABLE. The hint variable is nowPython3_EXECUTABLE.ci/windows-presubmit.batpasses-DPYTHON_EXECUTABLE:FILEPATH=..., which is likewise no longer read.Known limitation
Registering these tests puts them back into the official CI, which runs
-Dgtest_build_tests=ON -Dgmock_build_tests=ONfollowed bycteston both Linux and MSVC.gmock_output_testcompares output against a golden file and has historically been sensitive to MSVC output differences: 0a3b403 fixed it for MSVC on the same day fd36851 enabled these tests, and 097f64e reverted that fix a week later. I have only been able to verify Linux, so the MSVC behaviour of the golden comparison is unknown to me and would need checking before merging.What version of GoogleTest are you using?
0daf775 is the commit I reproduced on;
git rev-parse --short HEADreports 0daf775.What operating system and version are you using?
Ubuntu 22.04.3 LTS, running under WSL2 on Windows.
What compiler and version are you using?
g++ 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04.3).
What build system are you using?
cmake version 3.22.1. Python 3.10.12 is present on
PATH.Additional context
The build currently compiles
gmock_leak_test_andgmock_output_test_and then never runs them, so the cost of these tests is already being paid.