FWIW, I generally recommend against building the install target as a way to install the project (I just noticed I need to update part of my book to make this clearer). It is fine if you want all the defaults as is, but as soon as you want to do something that departs from that, you’re better off calling cmake --install .... It is clearer and more flexible. The defaults install to a system location (unless you change the value of CMAKE_INSTALL_PREFIX), which requires elevated privileges, and building with elevated privileges is very questionable to me. Some of my consulting clients have had headaches because of that in the past.
Doing the install as a separate step to the build also decouples “have I built everything” from “now install things”. It means you are responsible for ensuring everything to be installed has been built, but I’d question doing a make install without a preceding `make" anyway (I’m using “make” generically here, replace that with whatever build tool invocation you are using).
I’m departing from the focus of this issue here, but it is at least tangentially relevant. CMAKE_INSTALL_PREFIX is the default install location, and it will typically be something like /usr/local for Unix platforms. The value given by that cache variable is hard-coded into the install scripts. You can override it at install time using:
cmake --install /path/to/build/dir --prefix /overridden/base/install/dir
Trying to get that behavior by building the install target is not as clear or reliable, in my opinion.
Getting back to the main focus of the original post, if you’re seeing things installed to the wrong path even when using the --prefix argument to cmake --install, then we have a genuine problem that needs investigation. If the config file generated by gtest specifies the wrong path when the install is relocated like that, then chances are their config file is malformed.