linux-nvme/nvme-stas

meson: Dependency python3-libnvme not found

tbzatek opened this issue · 9 comments

libnvme_dep = dependency('python3-libnvme', fallback: ['libnvme', 'libnvme_dep'], version : '>= 1.2', required: false) # Only required to run the tests

A minor issue that I came across when packaging -rc5 in Fedora: the python3-libnvme dependency as in term of a pkg-config module is not provided by the upstream libnvme tarball and is not (typically) present in Fedora/RHEL either. Using the 2.0-rc5 tarball that has the following snippet (that was later changed by commit 8d691bd) I still get a meson failure even though the fallback argument is specified and which somewhat gets ignored by meson:

    #libnvme_dep = dependency('python3-libnvme', fallback : ['libnvme', 'libnvme_dep'], version : '>= 1.2')
    libnvme_dep = dependency('python3-libnvme', fallback : ['libnvme', 'libnvme_dep'])
Found pkg-config: /usr/bin/pkg-config (1.8.0)
Found CMake: /usr/bin/cmake (3.24.1)
Run-time dependency python3-libnvme found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency python3-libnvme

test/meson.build:15:4: ERROR: Automatic wrap-based subproject downloading is disabled

With the above mentioned change on git master I still get a non-fatal meson failure:

Found pkg-config: /usr/bin/pkg-config (1.8.0)
Found CMake: /usr/bin/cmake (3.24.1)
Run-time dependency python3-libnvme found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency python3-libnvme
Automatic wrap-based subproject downloading is disabled
Subproject  libnvme is buildable: NO (disabling)
Dependency python3-libnvme from subproject libnvme found: NO (subproject failed to configure)

I've changed the python3-libnvme in our builds to plain libnvme in the meantime, not sure what was your original intention though. But again, this is just a very minor glitch.

Have you tried the latest code? This should have been fixed by #267 which came after 2.0-rc5.

BTW, this dependency is only needed to run the tests. We added required: false to the dependency, which should solve this issue.

I did, it's not fatal anymore but the fallback doesn't work either.

Oh, I see, the meson fallback option is used to build a subproject in case of an missing dependency. That's obviously disabled within buildsystem env, forbidding internet access or embedding libraries in general. In any case the python3-libnvme pkg-config module requirement is an issue.

Are you running the unit tests as part of the buildsystem? If you are not running the tests, then it's not an issue.

The tests depend on python3-libnvme being installed. Or maybe the issue is that meson cannot find Python packages because they don't usually come with a .pc file. Is that the issue?

There's another way I can check for the presence of python3-libnvme, but it's not going to be a meson approach, and if the library is missing the tests will be skipped.

I'm open to suggestions.

Fixed by #275

@tbzatek - Please check that the above pull request fixes the issue. Thanks.

Nope, that made things actually worse. The test subdir and its meson.build file suggests that this target is always enabled, failing the basic build:

$ meson --wrap-mode=nodownload -Dman=true -Dhtml=true .build
The Meson build system
Version: 0.63.2
Source dir: /tmp/nvme-stas
Build dir: /tmp/nvme-stas/.build
Build type: native build
Project name: nvme-stas
Project version: 2.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 (lxml) found: YES (/usr/bin/python3) modules: lxml
Configuring nvme-stas.spec using configuration
Configuring .coveragerc using configuration
Configuring coverage.sh using configuration
Configuring defs.py using configuration
Configuring __init__.py using configuration
Configuring org.nvmexpress.staf.conf using configuration
Configuring org.nvmexpress.stac.conf using configuration
Configuring stafd.service using configuration
Configuring stacd.service using configuration
Configuring stas-config.target using configuration

test/meson.build:13:0: ERROR: Automatic wrap-based subproject downloading is disabled

I guess the --wrap-mode=nodownload meson argument should be crucial for a final test before making a release. It's a default of many distribution buildsystems. We don't need to run unit tests during the build. For the record, this is how the default Fedora meson command expansion looks like:

/usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload --auto-features=enabled . redhat-linux-build -Dman=true -Dhtml=true

(we've only added -Dman=true -Dhtml=true there)

Hi @tbzatek - Thanks for mentioning the --wrap-mode= option. With that I was able to reproduce the problem you mentioned. Hopefully this latest pull request will fix the issue once and for all.

Fixed by #279

Tested git master, everything works without any issue. Thanks!