Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
On Mon, Sep 16, 2019 at 05:38:47PM +0200, Andreas Tille wrote: > Determining dependency 'gtest_main' with pkg-config executable > '/usr/bin/pkg-config' > PKG_CONFIG_PATH: > Called `/usr/bin/pkg-config --modversion gtest_main` -> 1 There is no pkgconfig file for gtest_main in the archive. -- WBR, wRAR signature.asc Description: PGP signature
Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
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 signature.asc Description: OpenPGP digital signature
Bug#940327: Help needed to detect gtest_main (Was: Bug#940327: convert libpbseq-dev to Architecture: any)
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? Kind regards Andreas. [1] https://salsa.debian.org/med-team/pbseqlib -- http://fam-tille.de
Bug#940327: convert libpbseq-dev to Architecture: any
Package: libpbseq-dev
Version: 5.3.1+dfsg-2.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:blasr src:pbdagcon
The affected package fail to satisfy their cross Build-Depends, because
their dependency on libpbseq-dev is unsatisfiable. In general,
Architecture: all packages can never satisfy cross build dependencies
unless marked Multi-Arch: foreign or annotated :native. In this case,
such a marking would be fatally wrong, because the architecture
constraint would not be passed down to its own dependencies. This is
known as the "multiarch interpreter problem". In general, transitional
packages and metapackages should match the architecture of their
dependencies. Please consider applying the attached patch.
Helmut
diff --minimal -Nru pbseqlib-5.3.1+dfsg/debian/changelog
pbseqlib-5.3.1+dfsg/debian/changelog
--- pbseqlib-5.3.1+dfsg/debian/changelog2019-02-06 08:02:44.0
+0100
+++ pbseqlib-5.3.1+dfsg/debian/changelog2019-09-15 20:41:33.0
+0200
@@ -1,3 +1,10 @@
+pbseqlib (5.3.1+dfsg-2.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Covnert libpbseq-dev to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 15 Sep 2019 20:41:33 +0200
+
pbseqlib (5.3.1+dfsg-2.1) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru pbseqlib-5.3.1+dfsg/debian/control
pbseqlib-5.3.1+dfsg/debian/control
--- pbseqlib-5.3.1+dfsg/debian/control 2019-02-06 08:02:44.0 +0100
+++ pbseqlib-5.3.1+dfsg/debian/control 2019-09-15 20:41:09.0 +0200
@@ -31,12 +31,12 @@
This is a metapackage that depends on the pbseqlib component shared libraries.
Package: libpbseq-dev
-Architecture: all
+Architecture: any
Section: libdevel
Depends: ${misc:Depends},
- libpbdata-dev (>= ${source:Version}),
- libpbihdf-dev (>= ${source:Version}),
- libblasr-dev (>= ${source:Version})
+ libpbdata-dev (= ${binary:Version}),
+ libpbihdf-dev (= ${binary:Version}),
+ libblasr-dev (= ${binary:Version})
Description: library for analyzing PacBio sequencing data (development files)
Blasr_libcpp is a library used by blasr and other executables such as
samtoh5, loadPulses for analyzing PacBio sequences. This library contains
