Fix debug builds of cuda_bindings and cuda_core#1890
Conversation
Add -Wl,--strip-all to extra_link_args for wheel builds on Linux, matching the existing behavior in cuda_bindings/build_hooks.py. Without stripping, the 0.7.0 Linux wheel is ~30 MB (103 MB extracted) because every .so ships with debug_info. After stripping, extracted size drops from 103 MB to ~11 MB, bringing the wheel in line with the ~4-5 MB Windows wheels. Closes NVIDIA#1881 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
mdboom
added
cuda.bindings
|
/ok to test |
@mdboom, there was an error processing your request: See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/ |
|
|
||
| def build_editable(wheel_directory, config_settings=None, metadata_directory=None): | ||
| _build_cuda_bindings(strip=False) | ||
| _build_cuda_bindings(debug=True) |
There was a problem hiding this comment.
Could we add this here?
debug = config_settings.get("debug", True) if config_settings else True
That would make things a little more obvious (at least to me):
- Passing
-C="debug=False"or-C="debug=True"works universally (better than silently ignoring in editable builds) - For editable builds
debug=Trueis the default - For non-editable builds
debug=Falseis the default
There was a problem hiding this comment.
Oh, wait: we can only set to True if sys.platform != "win32":
debug_default = sys.platform != "win32"
debug = config_settings.get("debug", debug_default) if config_settings else debug_default
There was a problem hiding this comment.
It theoretically should still work on Windows, it will just have no effect.
There was a problem hiding this comment.
My idea was to avoid surprises: someone assuming it has an effect, then "troubleshooting" only to eventually find ah it's silently ignored.
There was a problem hiding this comment.
It'd be great to this catch here:
if sys.platform == "win32":
if debug:
raise RuntimeError("Debuggable builds are not supported on Windows.")
else:
| Editable installs have debuggable binaries by default. To build a non-editable | ||
| build, pass the `debug=True` configuration option to `pip` or `uv`: |
There was a problem hiding this comment.
Pass the pip / uv configuration option -C="debug=True" explicitly to request debuggable binaries. However, this is only needed for non-editable builds; for editable builds debug=True is the default.
|
/ok to test 2b01980 |
|
/ok to test 398b28d |
|
leofang
left a comment
leofang
left a comment
There was a problem hiding this comment.
Thanks for taking over, Mike! I have been hoping to get meaningful support for --config-settings. This is a good start (and solves multiple issues, size inflation and debug build)!
|
Since 398b28d was green and the latest change was doc-only, let me admin-merge this. |
3 participants
This builds on top of #1883 and is an alternative to it.
There are three problems this is trying to solve:
Since the move to
build_hooks.py, debug builds have been broken, since there is no way to pass--debuginsys.argvto the underlying build. This updates it to use a PEP 517 configuration flag instead, which can be passed throughpiporuvetc.Tying debug builds directly to editable installs seems like the wrong approach. Personally, I find editable installs to be more trouble than they are worth for compiled projects (such as this), and I like to install into multiple virtual environments with different versions of Python simultaneously, which you can't do with editable installs. This retains the behavior that editable installs are always debuggable, but also makes it possible to build non-editable installs as debuggable.
This ties debugging flags to stripping. IMHO, there is never a need to build with
-O0 -gand then strip symbols, so this links them together under a single config.