Skip to content

Latest commit

 

History

History
16 lines (15 loc) · 2.08 KB

File metadata and controls

16 lines (15 loc) · 2.08 KB

• - What changed: When we launch sourcekit-lsp we now pass --default-workspace-type buildServer if we detect a buildServer.json at the workspace root and the workspace isn’t a SwiftPM package. That tells SourceKit-LSP to talk to the Xcode build server instead of treating the project like a plain SwiftPM workspace.

  • Why it fixes the issue:
    • In an Xcode workspace, build settings (target triple, SDK, include paths, Swift macro plugins, derived data locations, SwiftPM dependencies, etc.) come from Xcode’s build system.
    • Without the build-server handshake, SourceKit-LSP fell back to a bare “syntax-only” open with just -sdk file.swift—no module search paths—so symbols that live in dependencies (your SQLiteData package) were invisible, leading to symbolNotFound.
    • With --default-workspace-type buildServer, SourceKit-LSP asks the Xcode build server for the full compile command. That includes the derived-data Build/Products and SourcePackages paths, so it can find SQLiteData (and other deps/macros), resolve the symbol, and return hover/definition data.
  • Do you need buildServer.json?
    • For Xcode workspaces/projects: yes, SourceKit-LSP relies on a build server to fetch accurate build settings. Xcode 15+ can generate buildServer.json (File > Packages > Generate Build Server Configuration…) or you can create it manually; you already have one in Noema/ so detection succeeds.
    • For pure SwiftPM packages: no—SourceKit-LSP reads Package.swift directly, so we skip the flag in that case.
    • If buildServer.json is missing in an Xcode project, SourceKit-LSP will default to SwiftPM mode and you’ll see the same missing-dependency behavior. Adding/generating the file (or invoking SourceKit-LSP with explicit --build- path/--configuration and a compilation database) is the proper fix.
  • Summary: The new flag makes monocle choose the Xcode build-server path when available, supplying the correct build settings for workspace targets and their SwiftPM dependencies, which is why dependency symbols now resolve.