Fix Swift build cannot find src/scanner.c.

[thiezn]

Missing src/scanner.c caused compile issues within Xcode.

Updated package.swift to follow the working tree-sitter-html Package.swift format.

Example output:

ld: warning: Could not parse or use implicit file '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/SwiftUICore.framework/Versions/A/SwiftUICore.tbd': cannot link directly with 'SwiftUICore' because product being built is not an allowed client of it Undefined symbols for architecture arm64:
"_tree_sitter_css_external_scanner_create", referenced from:
_tree_sitter_css.language in TreeSitterCSS.o
"_tree_sitter_css_external_scanner_deserialize", referenced from:
_tree_sitter_css.language in TreeSitterCSS.o
"_tree_sitter_css_external_scanner_destroy", referenced from:
_tree_sitter_css.language in TreeSitterCSS.o
"_tree_sitter_css_external_scanner_scan", referenced from:
_tree_sitter_css.language in TreeSitterCSS.o
"_tree_sitter_css_external_scanner_serialize", referenced from:
_tree_sitter_css.language in TreeSitterCSS.o
"_tree_sitter_javascript_external_scanner_create", referenced from:
_tree_sitter_javascript.language in TreeSitterJavaScript.o
"_tree_sitter_javascript_external_scanner_deserialize", referenced from:
_tree_sitter_javascript.language in TreeSitterJavaScript.o
"_tree_sitter_javascript_external_scanner_destroy", referenced from:
_tree_sitter_javascript.language in TreeSitterJavaScript.o
"_tree_sitter_javascript_external_scanner_scan", referenced from:
_tree_sitter_javascript.language in TreeSitterJavaScript.o
"_tree_sitter_javascript_external_scanner_serialize", referenced from:
_tree_sitter_javascript.language in TreeSitterJavaScript.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[1024jp]

The same as tree-sitter/tree-sitter-css#90.

I’m encountering the same issue, and I’ve confirmed that this PR resolves it in my project as well.

I hope this PR will be merged.

[amaanq]

How does this fix anything? The logic is not any different, which means however you've setup the project is messing with scanner detection. The point of the code is to have generated bindings that work for grammars with and without scanners.

[1024jp]

@amaanq Building the Swift package fails with undefined symbol linker errors for the JavaScript grammar’s external scanner because Package.swift conditionally includes src/scanner.c using a FileManager check with a relative path. Depending on how SwiftPM/Xcode evaluates the manifest, that relative path can be resolved against a different working directory than the package root, causing the check to return false even when scanner.c exists. As a result, the scanner is not compiled/linked and external scanner symbols remain undefined.

The change always includes src/scanner.c unconditionally. Since this repository does include src/scanner.c, the most reliable approach is to drop the dynamic check and hard‑code sources: ["src/parser.c", "src/scanner.c”].

[amaanq]

The reason it's conditional is because these bindings are auto-generated, and we want to have it such that grammar authors need not touch any of the bindings once they've been generated. Some grammars haven't been updated to use this new auto-detection yet, but this is what is in the main repository's templates. I'd be open to a fix that works for your use case, but I'd prefer to have the dynamic check. Every other language works just fine with some kind of dynamic check, so I believe it should be doable on Swift too.

[1024jp]

Thank you for taking the time to consider this.

Every other language works just fine with some kind of dynamic check, so I believe it should be doable on Swift too.

Unfortunately, the design philosophy is different. In Swift Package Manager manifests, the structure is currently expected to be resolved deterministically rather than through dynamic checks (cf. Swift Forums).

What makes this situation particularly problematic is that the current Package.swift configuration builds and tests successfully when the package is used on its own, but fails to build when it is consumed as a dependency by another program.

As a result, developers who want to use these languages via Swift Package Manager are currently submitting PRs to individual language repositories to address this issue.

The reason it's conditional is because these bindings are auto-generated, and we want to have it such that grammar authors need not touch any of the bindings once they've been generated. Some grammars haven't been updated to use this new auto-detection yet, but this is what is in the main repository's templates.

If the Package.swift manifest itself is auto-generated, it seems more appropriate to resolve this at the point where the manifest is generated.
I wasn’t aware that there is an official template in the main repository. It sounds like that template may also need to be updated. I would be happy to propose changes there as well.
Is the auto-generated code managed in the following repository?

https://github.com/tree-sitter/tree-sitter

[amaanq]

If the Package.swift manifest itself is auto-generated, it seems more appropriate to resolve this at the point where the manifest is generated.

No, because authors can and will add or remove the scanner file during development.

This works for me, let me know if it does for you (and then I can fix it upstream):

// swift-tools-version:5.6

import Foundation
import PackageDescription

let dir = Context.packageDirectory
var sources = ["src/parser.c"]
if FileManager.default.fileExists(atPath: "\(dir)/src/scanner.c") {
    sources.append("src/scanner.c")
}

[1024jp]

This works for me, let me know if it does for you (and then I can fix it upstream):

Great!
It works for me too. I’ve tried it in my local environment and confirmed it can be used as dependency.

[amaanq]

This has been merged upstream, so in the next CLI release we'll update these bindings

[1024jp]

@amaanq Thank you for implementation. I appreciate.