[FR]: The time cost of find_packe for Python is longer than expected

Does the feature exist in the most recent commit?

not find

Why do we need this feature?

In my project I added gtest via fetch function and then I noticed the obvious wait and felt tortured. Then the "NOTfind Python3" message appeared in the logs. I've noticed that this is the longest part of my project configuration process.

[cmake] -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter)

include(FetchContent)
FetchContent_Declare(gtest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0)
FetchContent_MakeAvailable(gtest)

I found that there is a find_package (Python3) in file internal_utils.cmake, and it does not belong to any function or macro, which is very inconsistent.
Then I noticed that py_xxx is only used when gtest_build_tests is enabled. So I boldly deleted find_package(Python3).
The effect is dramatic and the waiting is almost invisible. It seems certain that the time-consuming operation is here.
For the sake of rigor, I wrote a simple cmake project to measure the related time-consuming. CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(test)
include(FetchContent)

set(CTIME_STRING "%Y-%m-%d %H:%M:%S")
set(CTIME_STAMP "%s")
string(TIMESTAMP begin_time ${CTIME_STRING})
string(TIMESTAMP begin_time_stamp ${CTIME_STAMP})
message(STATUS "Current time: ${begin_time}  ${begin_time_stamp}")
#FetchContent_Declare(gtest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0)
#FetchContent_MakeAvailable(gtest)
find_package(Python3)

string(TIMESTAMP end_time ${CTIME_STRING})
string(TIMESTAMP end_time_stamp ${CTIME_STAMP})
message(STATUS "Current time: ${end_time}  ${end_time_stamp}")
math(EXPR diff_time "${end_time_stamp} - ${begin_time_stamp}")
message(STATUS "Time difference: ${diff_time} seconds")

The results are as follows.

[cmake] -- Current time: 2023-12-02 04:59:48  1701464388
[cmake] -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) 
[cmake] -- Current time: 2023-12-02 04:59:54  1701464394
[cmake] -- Time difference: 6 seconds

After some googling, I didn't find any relevant information about the time overhead of find_package :(

Considering that not everyone may use the gtest part, but according to the reference of internal_utils.cmake, this sentence will be executed no matter how the variables are set.

I hope to find_package only when the gtest_build_tests variable is ON.

Describe the proposal.

Wrapped by if(gtest_build_tests) outside find_package(Python3)

# old
find_package(Python3)
# new
if(gtest_build_tests)
  find_package(Python3)
endif()

I want to skip this time-consuming operation when I don't need to test, even though it's not too long for me:)

internal_utils.zip
CMakeLists.txt

This is the improved measurement result( Forgive my poor coding skills, I can only measure one second at the very least

[cmake] -- Current time: 2023-12-02 05:14:35  1701465275
[cmake] -- Current time: 2023-12-02 05:14:35  1701465275
[cmake] -- Time difference: 0 seconds

Is the feature specific to an operating system, compiler, or build system version?

I only have a Windows 10 computer, so I only tested it on this PC. I tested version 1.14.0 and checked the code of master, they are consistent(Except for different versions of Python)

-G "Visual Studio 17 2022" -T host=x64 -A x64
Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.

google / googletest