[C++] Bundled GTest CI jobs seem to #includeing GTest headers from somewhere else

[bkietz]

Describe the bug, including details regarding any error messages, version, and platform.

In #36334 I saw link errors in some CI jobs which build bundled GTest:

• AMD64 manylinux2014 Java JNI
• AMD64 macOS 12 C++

The symbol which is undefined is the internal FormatMatcherDescription function. That function is present in the bundled version of GTest (v1.11), but its signature is different in that version.

This suggests that somehow although we're building GTest v1.11 the tests are #includeing headers from a more recent version of GTest and we just haven't noticed before now.

Component(s)

C++

[lidavidm]

FWIW, that pipeline also installs GTest via Homebrew. We've seen similar issues before when we had both Conda-installed and bundled GTest in the same build (because we stuck the Conda include directory early on in the search path).

[bkietz]

The same link error occurs on the manylinux JNI job. I'll update the description with a more informative listing of the link errors

[bkietz]

The problem is actually more subtle: when the dependency's source is AUTO, ThirdpartyToolchain.cmake checks for a compatible system package. If the system package is not compatible, it will build a bundled version.

arrow/cpp/cmake_modules/ThirdpartyToolchain.cmake

Lines 287 to 292 in ad7f6ef

	if(COMPATIBLE)
	set(${DEPENDENCY_NAME}_SOURCE "SYSTEM")
	else()
	build_dependency(${DEPENDENCY_NAME})
	set(${DEPENDENCY_NAME}_SOURCE "BUNDLED")
	endif()

Building the bundled dependency adds its include directories... but it appends them so include directories which are already added have precedence. In this case the incompatible gtest headers from the conda environment are not being overridden by the bundled headers. It should be sufficient to use target_include_directories() with the BEFORE keyword to ensure that bundled projects' headers can override system headers

[bkietz]

I'm not sure how this interacts with #37483 yet. Among other things bundled gtest is no longer built as an ExternalProject. I'll open a PR using target_include_directories+BEFORE for the dependencies which still are ExternalProjects

[bkietz]

Nevermind, FetchContent_MakeAvailable does produce an ExternalProject.