use available sources of googletest instead of searching pre-built gtest

Question

use available sources of googletest instead of searching pre-built gtest

carandraug opened this issue 7 years ago · comments

David Miguel Susano Pinto commented 7 years ago

cmake's find_package is used to find an installed GTest for the test
suite. However, Google Test itself does not install anymore, and does
not recommend its installation or distribution of pre-built binaries
either. Instead, it recommends each project to compile Google Test.
See their FAQ [why is it not recommended to install a pre-compiled
copy of Google Test for example, into
/usr/local)?

Debian followed upstream recommendation and so there are no gtest
libraries. It seems that instead of find_packages, a project is
supposed to use ExternalProject and then FindGTest. I am guessing
Ubuntu and other Debian derivative projects will have the same issue
running the test suite. I do not know about Fedora and its
derivatives.

In the case of Debian, the headers are available as well as the entire
source tree in '/usr/src' for a project dependent on it for use. See
Debian's README on the
topic

David Miguel Susano Pinto · Answer 1 · Sun Jul 02 2017 21:26:59 GMT+0800 (China Standard Time)

The commit 3af7f39 at
https://github.com/carandraug/ome-common-cpp.git changes GTest.cmake
to use local sources at /usr/src/googletest/googletest/ (which is
where they are in Debian 9) with ExternalProject. This is my first
time with cmake so I'm guessing there will be a better way to do this
(the whole execute_process seems a bit more involved than I would
expect).

Also, I am guessing there should be a way to set GTEST_SRC_DIR and a
set of directories to search for googletest sources. I would guess
something like:

/usr/local/src/googletest/googletest
/usr/local/src/gtest
/usr/src/googletest/googletest
/usr/src/gtest

On a related note, gmock was merged into gtest, and each renamed
googlemock and googletest, so older versions (such as in Debian 8),
the directory would be /usr/src/gtest instead of
/usr/src/googletest/googletest (note the double googletest because
googletest is a subproject of googletest
distribution)

Roger Leigh · Answer 2 · Thu Jul 06 2017 00:50:35 GMT+0800 (China Standard Time)

Hi David.

Note that googletest 1.8 now allows proper installation again, which we do in our ome-cmake-superbuild component. This hasn't yet been picked up by distributions. The recommendation that it not be installed was pretty bogus; gtest is no different than any other C++ library. If you mix build/runtime types on Windows it can fail; but so would any other library.

We did previously build gtest as part of the build within each component; dropped in this commit. Initially this was by embedding, later by a configurable setting to point to the source. This was problematic for several reasons, and it scaled poorly once we split the codebase up into separate libraries in different repositories--we have to build gtest for each and every library we build. Embedding this way is also quite hacky; we need to make assumptions about the gtest/gmock cmake internals (targets etc.) which could break in a future release. Using find_package(GTest) decouples these concerns completely, even with earlier <1.8 releases.

We used to automatically build from /usr/src on Debian when building with travis, e.g. see this script. When packaging for Debian, this is what most packages seem to do as part of their package build. Setting up gtest is treated as a higher-level concern that's outside the scope of the package's build system. It's slightly less convenient when building the package by hand, but it's simpler and more robust, and avoids the awkward tight coupling of the gtest build.

Regards,
Roger

David Miguel Susano Pinto · Answer 3 · Thu Jul 06 2017 01:27:34 GMT+0800 (China Standard Time)

Hi Roger I totally get why using find_package is better. It is just that there is nothing to find in Debian and derivatives if googletest is installed from the repositories. Yeah, upstream reasons seem odd, and I agree, and others replied to their recommendation email with the same feeling. However, even if they enabled installation again (and current release 1.8 still has this on Makefile.am): https://github.com/google/googletest/blob/master/googletest/Makefile.am#L300 # Disables 'make install' as installing a compiled version of Google # Test can lead to undefined behavior due to violation of the # One-Definition Rule. their recommendation on the documentation is to still not install it. Maybe that's why Debian doesn't do it., I will raise it on Debian but do you have any link about upstream supporting installation again? I can't find anything like that from upstream. The changelog file for their 1.8 release only has notes until version 1.7. Their README text about how to use a shared library dates from 2010 which is older than this whole story of disabling install. I would much rather have a libgtest packaged in Debian than have to patch all ome-files components. Thank you David

Roger Leigh · Answer 4 · Thu Jul 06 2017 02:38:05 GMT+0800 (China Standard Time)

I can't say I looked at the automake build for gtest 1.8, but the cmake build install target now works properly. That's what we currently use to build. It's not pretty, but it's this file.

I'm not sure why there is a discrepancy between automake and cmake here; it might be an oversight. If so, a PR to fix automake to allow installation might be possible.

David Miguel Susano Pinto · Answer 5 · Fri Jul 07 2017 03:00:17 GMT+0800 (China Standard Time)

While looking for hints on upstream I found your question about this that has gone unanswered.

I ended up digging the commit google/googletest@98d988d where the cmake install rule was added. The commit comments explain that the reason it's there is to support superbuilds and installation in a staging area, and that upstream recommendation is still against installing the shared library. See google/googletest@98d988d#commitcomment-18900880