meson: build libnvme directly instead of as a subproject

[martin-belanger]

Change the build flow so that libnvme is no longer defined as a Meson subproject of nvme-cli. Instead, include libnvme's meson.build directly from the top-level meson.build.

This allows sharing a common ccan directory between nvme-cli and libnvme, and generates a single configuration header, project-config.h (formerly config.h), used by all components. The old file name conflicted with plugins/solidigm/solidigm-telemetry/config.h, hence the rename.

Also reformat all meson.build files to fix indentation inconsistencies and other cosmetic discrepancies.

@igaw - I tested different build options (enabling all possible options including generating the docs). Everything is working although I couldn't test cross-compilation and other exotic options (e.g. muon).

One thing that I wasn't sure about is the licensing which is slightly different between nvme-cli and libnvme. I have kept both licenses as follows. I made sure these would get used in the nvme.spec.in and libnvme.spec.in.

project(
    'nvme-cli', ['c'],
    meson_version: '>= 0.62.0',
    license: [
        'GPL-2.0-only',         # nvme-cli
        'LGPL-2.1-or-later',    # libnvme
    ],
    version: '3.0-a.1',
    default_options: [
        'c_std=gnu99',
        'buildtype=debugoptimized',
        'prefix=/usr/local',
        'warning_level=1',
        'sysconfdir=etc',
        'wrap_mode=nofallback',
    ],
)

[igaw]

Thanks for this work! There is some nice cleanups and improvements 👍

A few things should be addressed before the merge though. Nothing too serious IMO but the last point:

• the python code doesn't build for me:

FAILED: [code=1] libnvme/libnvme/_nvme.cpython-314-x86_64-linux-gnu.so.p/meson-generated_.._nvme_wrap.c.o
cc -Ilibnvme/libnvme/_nvme.cpython-314-x86_64-linux-gnu.so.p -Ilibnvme/libnvme -I../libnvme/libnvme -I. -I.. -Iccan -I../ccan -Ilibnvme -I../libnvme -Ilibnvme/src -I../libnvme/src -I/usr/include/json-c -I/usr/include/python3.14 -fvisibility=hidden -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 -O2 -g -fomit-frame-pointer -D_GNU_SOURCE -include project-config.h -fPIC -MD -MQ libnvme/libnvme/_nvme.cpython-314-x86_64-linux-gnu.so.p/meson-generated_.._nvme_wrap.c.o -MF libnvme/libnvme/_nvme.cpython-314-x86_64-linux-gnu.so.p/meson-generated_.._nvme_wrap.c.o.d -o libnvme/libnvme/_nvme.cpython-314-x86_64-linux-gnu.so.p/meson-generated_.._nvme_wrap.c.o -c libnvme/libnvme/nvme_wrap.c
In file included from /usr/include/python3.14/Python.h:71,
                 from libnvme/libnvme/nvme_wrap.c:203:
/usr/include/python3.14/pyport.h:660:35: error: missing ‘)’ after ‘__has_attribute’
  660 | #if _Py__has_attribute(fallthrough) && (!defined(__clang__) || \
      |                                   ^
./project-config.h:86:35: error: missing binary operator before token ‘(’
   86 | #define fallthrough __attribute__((__fallthrough__))
      |                                   ^
/usr/include/python3.14/pyport.h:25:49: note: in definition of macro ‘_Py__has_attribute’
   25 | #  define _Py__has_attribute(x) __has_attribute(x)
      |                                                 ^
/usr/include/python3.14/pyport.h:660:24: note: in expansion of macro ‘fallthrough’
  660 | #if _Py__has_attribute(fallthrough) && (!defined(__clang__) || \
      |                        ^~~~~~~~~~~

• installing with user rights fails

› meson install -C .build-incl-lib
ninja: Entering directory `/home/wagi/work/nvme-cli/.build-incl-lib'
ninja: no work to do.
Installing libnvme/src/libnvme.so.3.0.0 to /tmp/test/lib64
Installing nvme to /tmp/test/sbin
Installing /home/wagi/work/nvme-cli/libnvme/src/libnvme.h to /tmp/test/include
'/tmp/test/include/libnvme.h': Unable to set owner 0 and group 0: Operation not permitted, ignoring...
Installing /home/wagi/work/nvme-cli/libnvme/src/libnvme-mi.h to /tmp/test/include

• nvme seems not to be installed
• the script/release.sh script needs also be updated, though this is not necessary for this stuff. Just one thing to remember.
• we need a way to configure/build the library independent of nvme-cli. This means also we should be able to build nvme-cli without library. In this case the dependency for the library (e.g. OpenSSL) should not be required. This is an important feature the distros ask for.

To your questions:

• project-config.h: if we rename it, I'd say we should go with 'nvme-config.h'. Though we could just rename the plugin config.h. In the end this plugin needs to intergrate against the core code. :)
• in order to build with muon, you can use the script/build.sh script. This is also script which the CI build is using. So it the different configuration are supposed to work (debug/release, gcc/clang,...)

› ./scripts/build.sh -m muon
~/work/nvme-cli/.build-tools/muon ~/work/nvme-cli

[martin-belanger]

Good feedback. I'll start working on it. Thanks.

[martin-belanger]

I fixed the following:

• the python code doesn't build for me: The Python code should build now. The problem was that we define the macro fallthrough, which is clashing with the same macro definition in /usr/include/.../Python.h. This only happens with Python 3.14 since previous versions did not define fallthrough. This explains why this was building for me with Python 3.12 and not for you.
• build with muon: Fixed.
• project-config.h: I renamed project-config.h to nvme-config.h. I prefer using a nvme-specific file name (i.e. nvme-config.h) rather than a generic name (i.e. config.h) to avoid possible conflicts with 3rd party code in the future (better safe than sorry...)
• installing with user rights fails. I fixed it by removing the UID=0 and GID=0 from the install_mode. In other words, install_mode: 'rw-r--r--' instead of install_mode: '[rw-r--r--', 0, 0]. This way, files get installed with the current user/group instead of forcing user/group to root.

I have a few questions regarding the following items:

• the script/release.sh script needs also be updated: I'm not familiar with what this script does. If you don't mind, I will leave this one to you. 😉
• nvme seems not to be installed. Is this related to installing with user rights under /tmp/test/, or do you mean that nvme just does not get installed at all regardless of whether we install under /usr/sbin or elsewhere.
• we need a way to configure/build the library independent of nvme-cli. That's a good point. I'll need some time for this one...

[martin-belanger]

@igaw - Added 2 new meson options: -Dnvme=[auto,enabled,disabled] and -Dlibnvme=[auto,enabled,disabled]. Both default to enabled. These can be used to control whether to build the nvme executable and/or the libnvme.so library.

Regarding nvme not being installed, I was not able to reproduce the problem you observed. Please retest and let me know if you still see the issue.

[martin-belanger]

@igaw - Regarding your earlier comment:

we need a way to configure/build the library independent of nvme-cli. This means also we should be able to build nvme-cli without library. In this case the dependency for the library (e.g. OpenSSL) should not be required. This is an important feature the distros ask for.

Building the library (libnvme.so) without nvme-cli (nvme) is not a problem. However, building nvme-cli w/o the library present will result in a whole bunch of missing symbols (see example below). Maybe there's a gcc option to allow for that, but I'm not aware of it.

/usr/bin/ld: fabrics.c:(.text+0x3239): undefined reference to `nvme_ctrl_find'
/usr/bin/ld: fabrics.c:(.text+0x3281): undefined reference to `nvme_subsystem_next_ctrl'
/usr/bin/ld: fabrics.c:(.text+0x3319): undefined reference to `nvme_ctrl_get_subsysnqn'
/usr/bin/ld: fabrics.c:(.text+0x3326): undefined reference to `nvme_ctrl_is_persistent'
/usr/bin/ld: fabrics.c:(.text+0x3454): undefined reference to `nvme_free_ctrl'
/usr/bin/ld: fabrics.c:(.text+0x34e2): undefined reference to `nvme_host_is_pdc_enabled'
/usr/bin/ld: fabrics.c:(.text+0x34f2): undefined reference to `nvme_disconnect_ctrl'
etc...

Please let me know how you want to proceed.

[igaw]

/usr/bin/ld: fabrics.c:(.text+0x3239): undefined reference to `nvme_ctrl_find'
/usr/bin/ld: fabrics.c:(.text+0x3281): undefined reference to `nvme_subsystem_next_ctrl'
/usr/bin/ld: fabrics.c:(.text+0x3319): undefined reference to `nvme_ctrl_get_subsysnqn'
/usr/bin/ld: fabrics.c:(.text+0x3326): undefined reference to `nvme_ctrl_is_persistent'
/usr/bin/ld: fabrics.c:(.text+0x3454): undefined reference to `nvme_free_ctrl'
/usr/bin/ld: fabrics.c:(.text+0x34e2): undefined reference to `nvme_host_is_pdc_enabled'
/usr/bin/ld: fabrics.c:(.text+0x34f2): undefined reference to `nvme_disconnect_ctrl'
etc...

Please let me know how you want to proceed.

How do you build nvme-cli here? When building the project separately, the library needs to be build AND installed first., basically what ./scripts/build.sh distro does.

[martin-belanger]

How do you build nvme-cli here? When building the project separately, the library needs to be build AND installed first., basically what ./scripts/build.sh distro does.

Sorry, I misunderstood. When you said "This means also we should be able to build nvme-cli without library" I thought you meant that we should be able to build nvme-cli w/o libnvme present.

We are on the same page. This patch will allow building nvme-cli by itself as long as libnvme has previously been built and installed.

[igaw]

$  meson setup .build --debug --optimization=0 --reconfigure -Dlibnvme=enabled -Dnvme=disabled --prefix=/tmp/test
[...]
$ meson test -C .build
ninja: Entering directory `/home/wagi/work/nvme-cli-upstream/.build'
[113/113] Linking target libnvme/libnvme/_nvme.cpython-314-x86_64-linux-gnu.so
 1/47 libnvme - python-import-libnvme                                    OK              0.06s
 2/47 libnvme - python-create-ctrl-object                                OK              0.06s
 3/47 libnvme - python-sigsegv-during-gc                                 OK              0.06s
 4/47 libnvme - cpp-dump                                                 OK              0.05s
 5/47 libnvme - cpp-misc                                                 OK              0.05s
 6/47 libnvme - mi                                                       OK              0.04s
 7/47 libnvme - uuid                                                     OK              0.03s
 8/47 libnvme - uriparser                                                OK              0.03s
 9/47 libnvme - util                                                     OK              0.02s
10/47 libnvme - psk                                                      OK              0.02s
11/47 libnvme - ana                                                      OK              0.02s
12/47 libnvme - discovery                                                OK              0.01s
13/47 libnvme - features                                                 OK              0.01s
14/47 libnvme - mi-mctp                                                  OK              0.08s
15/47 libnvme - python-read-nbft-file                                    OK              0.10s
16/47 libnvme - tree                                                     OK              0.08s
17/47 libnvme - identify                                                 OK              0.05s
18/47 libnvme - logs                                                     OK              0.05s
19/47 libnvme - zns                                                      OK              0.05s
20/47 libnvme - misc                                                     OK              0.04s
21/47 libnvme - NBFT-auto-ipv6                                           OK              0.04s
22/47 libnvme - NBFT-dhcp-ipv6                                           OK              0.04s
23/47 libnvme - NBFT-rhpoc                                               OK              0.04s
24/47 libnvme - NBFT-static-ipv4                                         OK              0.03s
25/47 libnvme - NBFT-static-ipv4-discovery                               OK              0.03s
26/47 libnvme - NBFT-static-ipv6                                         OK              0.03s
27/47 libnvme - NBFT-Dell.PowerEdge.R760                                 OK              0.03s
28/47 libnvme - NBFT-Dell.PowerEdge.R660-fw1.5.5-single                  OK              0.02s
29/47 libnvme - NBFT-Dell.PowerEdge.R660-fw1.5.5-mpath+discovery         OK              0.07s
30/47 libnvme - NBFT-mpath+disc-ipv4+6_half                              OK              0.07s
31/47 libnvme - NBFT-ipv6-noip+disc                                      OK              0.07s
32/47 libnvme - NBFT-empty                                               OK              0.07s
33/47 libvnme - psk-json-tls_key-1                                       OK              0.05s
34/47 libvnme - psk-json-tls_key-2                                       OK              0.04s
35/47 nvme-cli - uint128                                                 OK              0.03s
36/47 nvme-cli - suffix_si_parse                                         OK              0.03s
37/47 libnvme - NBFT-bad-oldspec                                         EXPECTEDFAIL    0.07s   exit status 2
38/47 libnvme - NBFT-random-noise                                        EXPECTEDFAIL    0.07s   exit status 2
39/47 nvme-cli - suffix_binary_parse                                     OK              0.03s
40/47 libnvme - config-pcie-with-tcp-config                              OK              0.06s
41/47 nvme-cli - uint128-si                                              OK              0.02s
42/47 nvme-cli - argconfig_parse                                         OK              0.01s
43/47 libnvme - hostnqn-order                                            OK              0.06s
44/47 libnvme - config-pcie                                              OK              0.07s
45/47 libnvme - tree-apple-nvme                                          OK              0.08s
46/47 libnvme - tree-pcie                                                OK              0.10s
47/47 libnvme - kdoc                                                     OK              0.29s

• The nvme-cli tests are run during the libnvme only configuration.
• scripts/build.sh needs to be updated so that our CI build works.
• when installing the library with the above command the pc file has the wrong name

$ ls /tmp/test/lib64/pkgconfig
nvme-cli.pc
$ cat /tmp/test/lib64/pkgconfig/nvme-cli.pc
prefix=/tmp/test
includedir=${prefix}/include
libdir=${prefix}/lib64

Name: nvme-cli
Description: Manage "libnvme" subsystem devices (Non-volatile Memory Express)
URL: http://github.com/linux-nvme/libnvme/
Version: 3.0-a.1
Requires.private: json-c >= 0.13, libkeyutils, openssl >= 3.0.0
Libs: -L${libdir} -lnvme
Cflags: -I${includedir}

[martin-belanger]

@igaw - I just pushed fixes for the following two issues (good catch BTW).

• The nvme-cli tests are run during the libnvme only configuration.
• when installing the library with the above command the pc file has the wrong name

I'll be looking at build.sh now (although I'm not familiar with it)

[martin-belanger]

There are several places in build.sh where we have contradicting werror options. Here's an example:

config_meson_coverage() {
    CC="${CC}" "${MESON}" setup              \
        --werror                             \  # Treat warnings as errors
        --buildtype="${BUILDTYPE}"           \
        --force-fallback-for=libnvme         \
        -Dwerror=false                       \  # Do not treat warnings as errors
        -Db_coverage=true                    \
        "${BUILDDIR}"
}

Question: Do we want to treat warnings as errors or not?

And BTW, meson complains when we use both --werror and -Dwerror as shown below.

meson setup --werror --buildtype=release --force-fallback-for=libnvme -Dwerror=false /home/mbelanger/work/linux-nvme/nvme-cli/.build-ci
ERROR: Got argument werror as both -Dwerror and --werror. Pick one.

[igaw]

When the project were complete independent repos, I didn't want that building nvme-cli would break on a warning from libnvme. But since both project are now inside the same repo I'd say we an do werror for nvme-cli and libnvme.

[martin-belanger]

The ./script/build.sh distro has been fixed. The script continues to build libnvme and nvme-cli separately (like before). However, now that both libnvme and nvme-cli are in the same repo, and therefore will always be released together at the same version number, I'm not sure whether we still need to build them separately (maybe something we can ask distros?).

There are a couple of things that are not working, but I don't think they're related to my changes:

1. ./script/build.sh cross. I don't have the environment to do that.
2. ./script/build.sh static. This fails with a bunch of libcrypto linker errors, and I don't know what to do to fix it.

[igaw]

FWIW: I've added a section in the README, explaining how to use the existing containers to build cross:

• https://github.com/linux-nvme/nvme-cli?tab=readme-ov-file#container-based-debugging-and-ci-build-reproduction
• https://github.com/linux-nvme/nvme-cli?tab=readme-ov-file#5-cross-build-example

[igaw]

• when installing the docs -Ddocs=all, nvme-cli and libnvme docs are always installed, they don't honor
  -Dnvme and -Dlibnvme.
• the same for -Ddocs-build=true

Could you also rebase it to the latest master.

I am sure distros are able to build several packages from on source, I'd want to keep the builds and installs currently separately.

[martin-belanger]

@igaw - I rebased with latest master and fixed the docs to honor -Dnvme and -Dlibnvme.

Some of the GitHub Actions are failing. I'm investigating...

[martin-belanger]

A lot of the Actions are failing because GitHub is invoking the build.sh script from the libnvme/scripts/ directory. And I can't figure why it's doing that. 😕

Run libnvme/scripts/build.sh -b release -c clang -x

[martin-belanger]

FWIW: I've added a section in the README, explaining how to use the existing containers to build cross:

Thanks for the info. I tried it and it works. The only problem is that all the NBFT tests are failing because the utility nbft-dump is complaining of a bad format.

/nvme-cli/.build-ci/libnvme/test/nbft/nbft-dump-diff.sh: 8: /nvme-cli/.build-ci/libnvme/test/nbft/nbft-dump: Exec format error

[igaw]

Thanks for the info. I tried it and it works. The only problem is that all the NBFT tests are failing because the utility nbft-dump is complaining of a bad format.

This is likely caused by a missing hooks in the kernel for executing cross compiled binaries. That is the hook is missing in /proc/sys/fs/binfmt_misc/

[igaw]

It was a big task :) Let's go with this and improve the missing bits over time. Thanks a lot!