[Debian-med-packaging] Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)

The Wanderer wanderer at fastmail.fm
Mon Sep 16 17:14:20 BST 2019


On 2019-09-16 at 11:38, Andreas Tille wrote:

> Control: tags -1 pending
> 
> Hi,
> 
> I wanted to upgrade to the latest upstream version in Git[1] where
> upstream has changed the build system.  Its a bit irritating to use
> meson on top of cmake (at least I have never seen this before) and I
> think I have added all needed Build-Depends (locally - not commited
> yet):
> 
> 
> diff --git a/debian/control b/debian/control
> index b4d7424..c5a11fd 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -5,6 +5,10 @@ Section: libs
>  Priority: optional
>  Build-Depends: debhelper-compat (= 12),
>                 dh-exec,
> +               meson,
> +               pkg-config,
> +               cmake,
> +               googletest,
>                 zlib1g-dev,
>                 libhdf5-dev,
>                 libboost-dev,
> 
> 
> Despite I have added googletest it seems not be found:
> 
> 
> Library rt found: YES
> Configuring LibBlasrConfig.h using configuration
> Program tools/check-formatting found: YES (/build/pbseqlib-5.3.3+dfsg/tools/check-formatting)
> Pkg-config binary for MachineChoice.HOST is cached.
> Determining dependency 'gtest_main' with pkg-config executable '/usr/bin/pkg-config'
> PKG_CONFIG_PATH:
> Called `/usr/bin/pkg-config --modversion gtest_main` -> 1
> 
> CMake binary for MachineChoice.HOST is not cached
> CMake binary missing from cross or native file, or env var undefined.
> Trying a default CMake fallback at cmake
> Trying CMake binary cmake for machine MachineChoice.HOST at ['/usr/bin/cmake']
> Found CMake: /usr/bin/cmake (3.13.4)
> Extracting basic cmake information
> Try CMake generator: auto
> Called `/usr/bin/cmake --trace-expand .` in /build/pbseqlib-5.3.3+dfsg/obj-x86_64-linux-gnu/meson-private/cmake_gtest_main -> 0
>   -- Module search paths:    ['/', '/opt', '/usr', '/usr/local']
>   -- CMake root:             /usr/share/cmake-3.13
>   -- CMake architectures:    ['x86_64-linux-gnu']
>   -- CMake lib search paths: ['lib', 'lib32', 'lib64', 'libx32', 'share', 'lib/x86_64-linux-gnu']
> Run-time dependency gtest_main found: NO (tried pkgconfig and cmake)
> Looking for a fallback subproject for the dependency gtest_main
> 
> unittest/meson.build:14:0: ERROR: Automatic wrap-based subproject downloading is disabled
> 
> 
> 
> I also tried adding libgtest-dev in addition but this does not change
> the situation.
> 
> Any hint, what to do?

I'm not remotely an expert on any of the tools, systems, or packages
involved, but one thing I notice is that googletest doesn't seem to
install an actual .pc file, just a .pc.in:

$ dlocate gtest.*.pc
googletest:amd64: /usr/src/googletest/googletest/cmake/gtest.pc.in
googletest:amd64: /usr/src/googletest/googletest/cmake/gtest_main.pc.in

(And similar lack of suitable results from apt-file search, et cetera.)


The googletest package description says that it "does not contain a
library to link against, but rather the source code to build the google
test and mock libraries" (which fits with the fact that it isn't a lib*
package).

Typically the .pc file would be in the lib*-dev package, but in this
case, since there isn't a matching lib* package to install, I can easily
see why that might not make sense to do. (If it would, this would
probably be a wishlist item for the googletest package maintainers.)

/usr/share/doc/googletest/README.Debian states that

>> The Google C++ Testing Framework uses conditional compilation for 
>> some things. Because of the C++ "One Definition Rule", gtest and 
>> gmock must be compiled with exactly the same flags as your C++
>> code under test. Because this is hard to manage, upstream no
>> longer recommends using precompiled libraries [1].

>> [1] http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d

and that

>> If your build system uses CMake, the ExternalProject command can
>> be used to build gtest, then FindGTest can be used to find the
>> built library.

Clearly you need to build gtest before it can be picked up; this might
give some indication of how to go about doing so.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20190916/3bb4c63d/attachment.sig>


More information about the Debian-med-packaging mailing list