That was the problem. Upgrading XCode and using swift tools 6.2 solved the issue. Thanks.
It stopped working for me after updating from 6.2.2 to 6.2.3. The manifest file for the prebuild does get generated, but the prebuilt isn't there:
{"libraries":[],"version":1}
I am using the latest version of Xcode.
The manifest seems fixed now, thanks to swift-syntax prebuilt not available for Swift 6.2.3 Ā· Issue #9573 Ā· swiftlang/swift-package-manager Ā· GitHub.
That said, the problem didn't go away just like that automatically when building with Xcode. I also had to manually rm SourcePackages/workspace-state.json under DerivedData/<MyProject>/ to get SourcePackages/prebuilts/swift-syntax/ to appear downloaded (when subsequently resolving package versions).
(Alternatively, rm -rf SourcePackages, but downloading everything could take a while.)
2 Likes
there seems to be some kind of issue with prebuilts and --explicit-target-dependency-import-check=error
if i have a macro target like this,
.macro(
name: "BijectionMacro",
dependencies: [
.product(name: "SwiftSyntaxMacros", package: "swift-syntax"),
.product(name: "SwiftCompilerPlugin", package: "swift-syntax"),
]
),
it will always error out, unless i pass --disable-experimental-prebuilts.
1 Like
There is a GH Issue on that. I donāt have it handy.
I know that itās been mentioned a number of times already in this thread that prebuilts arenāt available for other targets. That being said, is this something that we could add support for?
We have a number of internal targets that vastly aid with using SwiftSyntax across all of the macros that we have. We have a target that has a plethora of convenience extensions on SwiftSyntax types, we have another that contain a bunch of factory methods for creating detailed diagnostics, and even one for simplifying argument parsing for the macro implementations. All of these targets are in packages whose only declared supported platform is macOS.
Since these are ānormalā targets we canāt take advantage of prebuilts without jamming all of this code into the macro target, which we donāt want to do since we have different internal packages in our codebase that utilize these convenience targets and would therefore require us to duplicate all of the convenience code across multiple different packages.
What kind of effort would we be looking at to support use in ānormalā targets, at the very least in this kind of manner? Are there any known workarounds? Any help would be greatly appreciated 
1 Like
Iāve been busy working on help in this area for Swift 6.3. As long as the libraries are only used for macros they will get the benefit of the prebuilts. Iāll do a whole forum post walking through the changes once theyāre available.
9 Likes
bumping this again because it seems the --disable-experimental-prebuilts workaround does not work at all if a project contains a dependency on a package that contains a macro, it will do nothing to mitigate the resulting compilation failure. this happens even if the project does not use the macro at all. the mere existence of the macro in the upstream repo causes the build to fail.
iām not very confident in speculating why, but cursory inspection of CI logs makes me wonder if --disable-experimental-prebuilts is only affecting the root package, while --explicit-target-dependency-import-check=error is being applied to the entire build tree.
i get the sense that this is lacking attention because --explicit-target-dependency-import-check=error is possibly seen as optional. it is not. in a Swift code base of nontrivial size, that configuration is mandatory, it is simply not possible to develop Swift projects effectively without --explicit-target-dependency-import-check=error. if that setting is not enabled, incremental builds simply cannot be trusted.
3 Likes
@taylorswift Is there a GitHub Issue tracking this? Can you post the link so others may follow as well. Thanks!
1 Like