-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: do not check extension module file name against expected suffix #322
Conversation
Checking that the extensions modules filenames end with a suffix accepted by the current Python interpreter assumes that the wheel being assembled is for the same Python platform. This is not true when cross-compiling. The check protects against a very unlikely occurrence and makes life harder for tools that allow cross-compiling Python wheels. Remove it. See mesonbuild#321.
+1 for doing this. We can either remove the check completely, or remove it when we know we're cross-compiling. Which is something that I think we anyway need to know - we already do know on macOS, and outside of macOS it's a matter of checking for a cross file in config-settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can either remove the check completely, or remove it when we know we're cross-compiling.
I'd prefeer if we just kept the check, but limited to when we are not cross-compiling.
I added the check, but I came to the conclusion that it is not a good idea. Among other things, it prevents installing a data file in |
A data file that ends with |
Oh, you are right. I forgot about the double extension check. However, if someone goes into the trouble of putting something that looks like a Python extension module for the wront interpreter version in |
Thanks @rgommers for linking this PR from #321, I missed it somehow when browsing #321. While thinking my self how can I fix this issue with a patch applied upon the First of all (easy), the docstring wasn't trimmed: diff --git i/mesonpy/__init__.py w/mesonpy/__init__.py
index 78db5d8..5832d4e 100644
--- i/mesonpy/__init__.py
+++ w/mesonpy/__init__.py
@@ -341,10 +341,6 @@ class _WheelBuilder():
and .so on other platforms) and, if they all share the same
PEP 3149 filename stable ABI tag, return it.
- All files that look like extension modules are verified to
- have a file name compatibel with what is expected by the
- Python interpreter. An exception is raised otherwise.
-
Other files are ignored.
""" Secondly, this meson-python/mesonpy/__init__.py Lines 351 to 355 in 961fb56
Doesn't assume that the "Host" machine and "Build" / "Target" machine have the same "shared object" file extension ( |
Good points, thanks @doronbehar.
It's not too much to ask - I'm hoping we can make that work at some point. But in practice it's not that common to do that, so it may take a while before we need to work around this one. In the meantime, there's some bigger cross-compilation fish to fry, in Meson itself and in dealing with |
Here's a small fixup PR with docstring and a comment to that condition: #349 |
Checking that the extensions modules filenames end with a suffix accepted by the current Python interpreter assumes that the wheel being assembled is for the same Python platform. This is not true when cross-compiling. The check protects against a very unlikely occurrence and makes life harder for tools that allow cross-compiling Python wheels. Remove it.
See #321.