Building with a debug python build should generate a debug build

[ngoldbaum]

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.

[lithomas1]

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.

[FFY00]

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.

[rgommers]

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 python-dbg and then matching packages like python-numpy-dbg, python-scipy-dbg. I'd also say that a debug Python build is nothing special here (or, Python as a package is nothing special, only the limitations of PyPI make it different) - it's just another package.

As for the details:

• I wouldn't use c_args: ['-g', '-O0'], like @ngoldbaum does, I'd just add -Ddebug-true. The -g is a GCC-specific way of writing -Ddebug=true. And I would not touch optimization settings; a typical default for Meson is debugoptimized.
• I don't know without looking in more detail how to tell whether a Python install is a debug build. And there's corner cases like the user passing in a cross file that need a simple answer/implementation.

[ngoldbaum]

My understanding is that setuptools will use sysconfig to get the compiler flags used to build python itself and reuses those flags when building C extensions. This behavior is probably what most python developers would expect since setuptools was ubiquitous until recently. I'm not saying that meson-python should necessarily do that (since it makes using a different compiler than whatever was used to build Python painful, among other issues), just that is what most people who work on C extensions would expect.

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. cp310-cp310d-linux_x86_64 for debug versus cp310-cp310-linux_x86_64 for a regular build). Just because you've built a wheel doesn't necessarily mean it's stripped and optimized. While I agree that the main purpose of wheels is distribution, I don't think there's a way to use meson-python without ultimately generating a wheel that will be installed, even when working locally on some development task. That's why meson-python should consider that use-case too, or at least try to make it more streamlined (e.g. gh-154, gh-47).

[rgommers]

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.

There's also a debug platform tag for wheels (e.g. cp310-cp310d-linux_x86_64 for debug versus cp310-cp310-linux_x86_64 for a regular build).

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.

[ngoldbaum]

Is that actually used?

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.

[rgommers]

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.

Ah, then it's also arguably a bug that there isn't any debug info inside:)