Repository navigation
build: honour --use-system-libuv on MSVC, document the option - #188
Merged
Merged
Conversation
The build_ext option already links against a system libuv instead of the bundled copy, but the README never mentions it. Add a short note with the command, verified on macOS arm64 with Homebrew libuv 1.53.0: the extension builds, otool shows it linked to libuv.1.dylib, and a TCP echo runs on the winloop loop. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Say the linker is asked for uv by name rather than guaranteed to link dynamically, note the MinGW default, and note that non-MinGW Windows builds always use the bundled libuv. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
The MSVC path compiled the vendored libuv sources and ignored the flag. With the flag set, skip the vendored sources and vendored include dirs, and link uv.lib; MSVC finds uv.h and uv.lib through INCLUDE and LIB. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Found while verifying the MSVC flag in CI: the import failed with DLL load failed until the libuv bin directory was added with os.add_dll_directory, because Python 3.8+ ignores PATH for extension dependencies. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Vizonex
approved these changes
Nov 5, 2026
Vizonex
left a comment
Vizonex
left a comment
Owner
There was a problem hiding this comment.
For now this seems like a good solution. Know that 3.14t and 3.15t has a freezing bug that is being fixed (Currently I'm looking at a writing a new C-API for _asyncio to replace winloop.loop.Future and still provide cdef class extensions).
Owner
|
whoops, I'm trying to reopen give me a sec. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What do these changes do?
They make
--use-system-libuvwork on MSVC builds. So far the flag only took effect on MinGW (since #65). On MSVC the vendored libuv was always compiled in. With the flag, the MSVC build no longer compiles the vendored sources, drops thevendor/libuvinclude paths and links against an installeduv.libinstead.I kept it inside the existing
build_extensionsbranch rather than starting the biggersetup.pycleanup you described in #39, so the change stays small (+12/-6 insetup.py).Are there changes in behavior for the user?
Not unless they pass the flag. With it, MSVC finds
uv.handuv.libthrough the usualINCLUDEandLIBvariables, anduv.dllhas to be found when winloop is imported. Python 3.8+ no longer searchesPATHfor an extension's DLLs, so users (or a conda-forge recipe) need to callos.add_dll_directoryfirst. The flag doesn't do that for them, so I added a short README section about it.Is it a substantial burden for the maintainers to support this?
I don't think so. It is one extra branch, and the default build does not change.
Related issue number
Part of #39: the MSVC side of the conda-forge Windows case.
Checklist
How I checked it (windows-latest, Python 3.12, libuv 1.53.0 from vcpkg)
import winloopplus a small TCP echo test pass: https://github.com/evnchn/Winloop/actions/runs/41439707418C1083: Cannot open include file: 'uv.h', which shows the vendored headers really are out of the build. The same job on the commit before this change (3ce699b) builds fine, so the flag used to be ignored: https://github.com/evnchn/Winloop/actions/runs/41439711612🤖 Generated with Claude Code