Skip to content

Conversation

@martin-belanger
Copy link

When building a pip (PyPI) package, do not set the libnvme.so version to major.minor.patch (e.g. libnvme.so.3.0.0), but instead just set it to the major (e.g. libnvme.so.3). pip/wheel do not care about the full versioning, and since symbolic links cannot be installed via pip (i.e. libnvme.so.3 -> libnvme.so.3.0.0), it's better to just skip the major.minor.patch versioning for PyPI.

To support this we're introducing a new config flag "pypi" to let meson know we're building for pip/PyPI.

@igaw - After doing more testing I found that the previous fix to set the symbolic links did not work. This PR reverts the previous change and provides a simpler fix more in line with PyPI packages.

When building a pip (PyPI) package, do not set the libnvme.so
version to major.minor.patch (e.g. libnvme.so.3.0.0), but instead
just set it to the major (e.g. libnvme.so.3). pip/wheel do not care
about the full versioning, and since symbolic links cannot be
installed via pip (i.e. libnvme.so.3 -> libnvme.so.3.0.0), it's
better to just skip the major.minor.patch versioning for PyPI.

To support this we're introducing a new config flag "pypi" to let
meson know we're building for pip/PyPI.

Signed-off-by: Martin Belanger <[email protected]>
martin-belanger referenced this pull request Jan 14, 2026
When we "pip install" a PyPI package previously built with
"pipx run build --sdist", there is a missing symbolic link
in the directory where libnvme.so.X.Y.Z is installed.

For example, let's say we build libnvme.so.3.0.0. There needs to
be a symbolic link installed along with the library as follows:

libnvme.so.3 -> libnvme.so.3.0.0

Signed-off-by: Martin Belanger <[email protected]>
@igaw
Copy link
Collaborator

igaw commented Jan 14, 2026

Just as idea: doesn't PyPi set a build environment variable? Couldn't we use that one as input? Or is this a stupid idea?
Also would it make sense to toggle the other options (-Dnvme=disabled...) based on this one?

@martin-belanger
Copy link
Author

I'm not familiar with the PyPI build environment variables. Heck, I did not know anything about building PyPI until a few days ago... 😄. But I'm curious to know what you have in mind.

Yes, it does make sense to toggle all the options based on the -Dpypi being set. I can work on that.

@martin-belanger
Copy link
Author

@igaw - Note that toggling the other options based on -Dpypi=true is not 100% foolproof. That's because we can't actually overwrite the value of an option returned by get_option().

For example, we can overwrite options like this:

want_pypi = get_option('pypi')
if want_pypi
   want_tests = false
   want_nvme = false
   want_libnvme = true
   etc...
else
   want_tests = get_option('tests')
   want_nvme = get_option('nvme').disabled() == false
   want_libnvme = get_option('libnvme').disabled() == false
   etc...
endif

We just need to make sure to use if want_<option> instead of if get_option('<option>') in all the meson.build files.

Would you like me to proceed with this change?

@igaw
Copy link
Collaborator

igaw commented Jan 14, 2026

Okay, sounds like asking for trouble. Let's go with your solution. If it works we can still clean it up if needed.

@igaw igaw merged commit 728cee5 into linux-nvme:master Jan 15, 2026
20 checks passed
@martin-belanger martin-belanger deleted the add-pypi-meson-option branch January 15, 2026 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants