Repository navigation
Let Windy own loadExtensions and build the CPU backend in CI - #68
Merged
Merged
Conversation
Silky defined its own no-op loadExtensions for the Metal and CPU backends. Windy already exports one on Win32 for DirectX, Vulkan and CPU, so on Windows CPU builds both were visible and every loadExtensions() call in the examples was ambiguous: Error: ambiguous call; both platform.loadExtensions() and silky.loadExtensions() match for: () That broke all eight examples with -d:useCpu on Nim 2.2.10 and 2.2.12. CI never noticed because the CPU backend was not in the matrix. Silky already does `export windy`, so dropping the local copy leaves callers with Windy's symbol and nothing else. Windy is gaining the matching no-op on macOS for Metal and CPU (treeform/windy PR), and the lock file should move to that Windy once it lands. Add a Windows CPU cell to the CI matrix and run the existing CPU smoke test in every cell so this stays fixed. The test is a no-op unless -d:useCpu is set on Windows. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
treeform/windy#195 is merged, so the macOS Metal and CPU backends get their no-op loadExtensions from Windy and the previous commit's removal of Silky's copy no longer leaves macOS without one. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
Problem
Every example fails to compile with
-d:useCpuon Windows, on both Nim 2.2.10 and 2.2.12:Silky defined its own no-op
loadExtensionsfor the Metal and CPU backends. Windy already exports one on Win32 for DirectX, Vulkan and CPU. On a Windows CPU build the example imports both, and the compiler cannot choose between two exported procs with the same name and signature, so the call is ambiguous. CI never caught it because the CPU backend is not in the matrix.Fix
Only Windy should export
loadExtensions. Silky already doesexport windy, so removing Silky's copy leaves callers with exactly one symbol. Windy gains the matching no-op on macOS for Metal and CPU in a companion PR on treeform/windy.CI gets a
Windows CPUcell and runs the existingtests/test_cpu_backend.nimsmoke test in every cell (it is a no-op unless-d:useCpuon Windows), so the CPU backend stays green.Dependency
macOS with
-d:useMetal4or-d:useCpuneeds the Windy PR merged andnimby.lockmoved to that Windy commit, since the lock still pins Windy 0.4.4. Windows, Linux and Emscripten are unaffected by that. I did not bump the lock here so it can point at the merge commit rather than a branch SHA.Testing
On Nim 2.2.12 with this change, all eight examples compile with OpenGL, DirectX, Vulkan and CPU backends (32 of 32), and
test_cpu_backendpasses with-d:useCpuand skips cleanly on the other backends.🤖 Generated with Claude Code