> There exists no corresponding library binary package libgtest1.
Correct and for a good reason you mentioned below. > This is in accordance with a recommendation of the upstream authors, [...] > but it is in conflict with the well-established standard way > of how libraries are distributed in Debian. This is incorrect. Header-only libraries are present in the Debian archive, such as libboost-dev or libeigen3-dev. A -dev package does not automatically have an accompanying shlib package. > Somehow I discovered that there is a libgtest-dev in Debian, and a > FindGTest in cmake. So I installed libgtest-dev on my system, removed > ThirdParty/gtest from my project, changed CMakeList.txt files, tried > to rebuild the project, saw that FindGTest did not find the library, > investigated the problem, and finally discovered that libgtest-dev > is deceptive in that it does not pull in the binary without which > it is useless. This has nothing to do with libgtest-dev being deceptive, but with you failing to understand how modern integration of GTest with CMake is supposed to happen in accordance with upstream recommendations. Modern integration uses ExternalProject_Add to fetch the gtest source, build its byproducts somewhere in the build-tree and either point FindGTest to this location or set the GTEST_* variables manually. You were right to strip ThirdParty/gtest from the source tree but did not modify the CMake list files appropriately. If upstream uses ExternalProject_Add (which they should), then all you have to do is modify it to use /usr/src/gtest instead of the vendored or downloaded version. Otherwise, you'd have to investigate where the gtest source are utilized in the CMake list files and modify the path there. This bug should be tagged as won't fix. Ghis
