-
Notifications
You must be signed in to change notification settings - Fork 440
Add a dynamic and static library product of SwiftSyntax to Package.swift #26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci Please test |
CC @nkcsgexi |
Thanks, @ahoppen ! I was just about to do this myself. Your comment makes total sense. |
Wait, i get this error when building locally:
We don't wanna change either the dylib name or the module name. Any idea how to resolve? |
@nkcsgexi How did you get this error? I cannot reproduce it on my machine. Renaming the product name to something that doesn't include a dash should probably resolve the issue, although I don't quite understand what the issue is. |
I can see the error either by invoking Swift-side build script:
or invoking the swift-syntax build script alone:
I'll revert this change for now till we have a good solution for preserving dylib names; plus linking SwiftSyntax statically makes sense to be the default setting for our users for now. |
I was able to reproduce the issue if using |
yeah, unfortunately using the SwiftPM from the environment is almost a hard requirement for us to submit. We can put a ping on this and wait till SwiftPM from the environment is up to date and then change the Package.swift file to the right configuration. |
Ah, OK. Well. In that case it looks like we can only make this change once the next version of SwiftPM has shipped. |
Prevent breaking at the space in `else {` of a `guard` statement.
Address #25 (comment).
We should not specify the type of the library product via an environment variable. Instead a cleaner approach is to have both a static and a dynamic library product in the package and just build the type of the library that is needed.