-
Notifications
You must be signed in to change notification settings - Fork 66
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
Building with a debug python build should generate a debug build #207
Comments
Hmmm. I think I would lean more towards keeping the default as a release build, with a command line option to toggle. Wheels are meant to be distributed, and having debug symbols makes it quite a bit bigger. I think users would also expect to have optimized code within a wheel. |
I think the proposal here is that the Python interpreter itself is a debug build, meson-python should default to a debug build in Meson, and if the interpreter is a release build, default to a release build. The proposed default behavior seems a bit surprising to me, I don't think I would expect it, and I generally treat debug interpreters and building extensions with debug arguments as different things that'd I would change independently. However, I don't maintain a lot of Python extensions, so I can't really tell if these are normal expectations. Perhaps @rgommers could provide some better feedback. |
The proposal makes sense to me. The only reason I'd want a debug build of Python is to do some actual debugging - at which point you do want debug builds of everything else as well (may be necessary, can't really hurt). Some Linux distros even distribute packages like that, e.g. Ubuntu 18.04 has As for the details:
|
My understanding is that setuptools will use Until Python 3.8 the debug build of Python had a different ABI than the regular build, meaning that all packages had to be rebuilt for the debug build and wheels wouldn't work unless explicitly built as debug builds, so it's relatively common to expect to rebuild an entire dependency tree with debug support. Since Python 3.8 that's no longer the case, but I think it still impacts expectations for how things "should" work. There's also a debug platform tag for wheels (e.g. |
Very useful context, thanks @ngoldbaum. Taking over other compiler flags we definitely don't want to do - as you point out it makes using a different compiler different. But the debug flag is a bit of a special case.
Is that actually used? It does make sense to me to support it, because a local debug build may otherwise pollute Pip's cache and be preferred the next time you want a regular install. |
Yup, in fact meson-python (or perhaps build?) currently generates a wheel for my project with the debug ABI tag when I build my project with a debug python. It's also mentioned in PEP 425. I don't know whether anyone is shipping debug wheels on pypi. |
Ah, then it's also arguably a bug that there isn't any debug info inside:) |
Closes mesonbuildgh-461 Closes mesonbuildgh-207 Also xref mesonbuildgh-459 and mesonbuildgh-441 which are already closed but contain discussion relevant to debug builds.
Closes mesonbuildgh-461 Closes mesonbuildgh-207 Also xref mesonbuildgh-459 and mesonbuildgh-441 which are already closed but contain discussion relevant to debug builds.
Currently meson-python will generate the same wheel for a debug python build and a regular python build. I think this violates the principle of least surprise, since if one is using a debug python build I think one expects the C extensions to also be debug builds. This is what setuptools currently does.
I'm working around this by manually passing compiler flags to the meson build for my C extension when I need a debug build.
gh-154 would enable setting flags from the command line, so I wouldn't need to edit
meson.build
, however I think it's still worth having better default behavior for debug builds.The text was updated successfully, but these errors were encountered: