Fix Windows build: gate EventSource/FoundationNetworking on canImport in HTTPClientTransport - #271
Open
lionheart-jhanke wants to merge 1 commit into
Conversation
…ntTransport
The package manifest already limits the EventSource dependency to Apple
platforms, but HTTPClientTransport.swift gates its import and the SSE
code paths on `#if !os(Linux)`. On any other non-Apple platform (e.g.
x86_64-windows-msvc) the module is absent yet the import is still
compiled, so the whole MCP target fails with:
HTTPClientTransport.swift:5:12: error: no such module 'EventSource'
Gate on capabilities instead of naming Linux:
- `#if canImport(EventSource)` for the import, the SSE listen loop, and
connectToEventStream -- selects exactly the same code on Apple and
Linux as before
- `#if canImport(FoundationNetworking)` for the data(for:) vs bytes(for:)
split and the matching processResponse overloads, since
URLSession.AsyncBytes only exists in Darwin Foundation
- reword the two log messages that named Linux
No behavior change on Apple or Linux; the MCP target now compiles for
x86_64-unknown-windows-msvc (verified with Swift 6.3.3).
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
1 participant
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.
Fixes #261.
Package.swiftprovides theEventSourceproduct on Apple platforms only, butHTTPClientTransport.swiftgates the import and the SSE code paths on#if !os(Linux). On Windows the import is compiled without the module being available, so any target depending onMCPfails withno such module 'EventSource'. (#261 has the full analysis; the guards drifted when #143 moved the platform logic into a.when(platforms:)condition.)This keys the guards off availability instead of naming platforms, along the two axes that actually differ:
#if canImport(EventSource)for the import, the SSE listen loop, andconnectToEventStream— on Apple and Linux this selects exactly the code selected today, because the manifest grants EventSource to all Apple platforms and denies it to Linux.#if canImport(FoundationNetworking)for thesession.data(for:)vssession.bytes(for:)split and the pairedprocessResponseoverloads —URLSession.AsyncBytesis a Darwin-Foundation capability, independent of EventSource, so this names the real dependency rather than folding it into the SSE guard. Selection today is likewise identical on Apple and Linux.Windows takes the same graceful-degradation path Linux already takes: JSON request/response works, SSE streaming logs a warning and is skipped.
Verified:
swift build --target MCPsucceeds for x86_64-unknown-windows-msvc with Swift 6.3.3 (all 113 sources); before the patch it fails atHTTPClientTransport.swift:5. No selection change on Apple or Linux by construction, since each new condition is equivalent to the old one on those platforms.🤖 Generated with Claude Code