-
-
Notifications
You must be signed in to change notification settings - Fork 617
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
Support testing via SPM #935
Conversation
…ourcery but library, not executable. Reason: linker has problems linking test target against executable.
…abled since it needs additional configuration
…ore. Re-enable JS spec.
this is great 👏🙇♂️ |
@HeMet might need to add this setup https://github.com/muter-mutation-testing/muter/blob/master/Package.swift#L105 so that tests when run through Xcode project rather than just from console work correctly |
Thanks. I'll try. |
/// We need to manually add an -rpath to the project so the tests can run via Xcode | ||
/// If we are running from console (swift build & friend) we don't need to do it | ||
func hookInternalSwiftSyntaxParser() { | ||
let isFromTerminal = ProcessInfo.processInfo.environment.values.contains("/usr/bin/swift") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use this approach of having the flag but don't use /usr/bin/swift
, link to the one that's bundled in the repo as this is proper way to do it, that way the SDK matches the dylib regardless of toolchain user has
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should it check then if not /usr/bin/swift
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't really care about user setup for the generic sourcery use, that's why we bundle our own stuff so we don't need to rely, their setup can only affect Swift templates and there are some checks there as far as I remember
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@krzysztofzablocki I understand that. I have already fixed the path the hook adds to -rpath
so it points to bundled version of the library.
But what about isFromTerminal
flag? You said /usr/bin/swift
should not be used. So what should we check to determine if -rpath
should be modified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this use is fine, it just checks if its using swift build but it's not pulling anything from it
Package.swift
Outdated
if !isFromTerminal { | ||
package | ||
.targets | ||
.filter(\.isTest) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-rpath
to the bundled version of SwiftSyntax should be added to the Sourcery
target too. Otherwise it won't find the library when launched during TemplatesTests
.
Strangely, the same executable runs normally when launched from terminal.
…when launched during TemplatesTests.
I don't get why CI failed. |
@krzysztofzablocki Is there something I can do to push the PR forward? |
@HeMet this is all great work 👌 and it will get merged soon, I'm just literally spending 100% of my free time on Sourcery Pro companion app atm, should be live in a week or so and then I'll get back on track on this and other pr's and issues https://twitter.com/merowing_/status/1379708785476968449?s=21 |
@HeMet there is an issue with Swift templates crashing in tests after those changes, and one blocker there which I don't think is necessarily related to tests failing is that we package Swift Runtime files into a single file for Swift Templates since they are compiled swift programs, I tried moving that logic to Package.swift but it seems I can't write to file there (permission denied). Would you mind taking a look at those 2 things? |
Yes, I'll investigate these issues. |
@HeMet I spoke with someone that knows SPM really well and it seems package is sandboxed so that step will have to be manual, we can put it in rake, so if you can figure out why tests fail on swift templates we can probably move along with this pr |
Add 'import Foundation'
There was compilation issue with
That step is a part of |
@HeMet i think you are right in regards to tests, they fail on older commits too on my new m1 so just local config issue, as for the rake no, we need to copy code from Swift template build phase in normal Xcode project, take a look there is a script call there that generates it |
Generated by 🚫 Danger |
Yeah, I've realized I missed that step while porting tests to SPM. Also, I think that will help with scripting in the future https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md For now, maybe it is too early to drop Xcode Project and switch to SPM entirely. |
@HeMet nah, let's kill workspace and pods because it's such a hassle, can you just move that script to boilerplate rake step? I think that's all we need |
Sorry, I have no experience with the rake :) |
@HeMet that's fine I can do it, thanks for contributing this 🙇 |
Thanks for the great tool :) |
e1b75db
to
8d1ff6c
Compare
included in #951 |
This patch adds support for testing via Xcode + SPM or SPM.
Minimum changes made for Xcode project and project structure.
SourceryLib
target introduced since the linker has problem to link tests againstsourcery
executable.Since SPM has no support for running scripts as part of build process, code generation for
TemplatesTests
moved to the test itself. That means what code generated forLinuxMain.swift
is not compiled as a part of the target. This affect SPM only.