Skip to content
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

Closed
wants to merge 36 commits into from
Closed

Conversation

HeMet
Copy link
Collaborator

@HeMet HeMet commented Apr 2, 2021

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 against sourcery 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 for LinuxMain.swift is not compiled as a part of the target. This affect SPM only.

@krzysztofzablocki
Copy link
Owner

this is great 👏🙇‍♂️
it was on my list to do so we can kill the app project 🔥

@krzysztofzablocki
Copy link
Owner

@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

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 2, 2021

@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")
Copy link
Owner

@krzysztofzablocki krzysztofzablocki Apr 2, 2021

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

Copy link
Collaborator Author

@HeMet HeMet Apr 2, 2021

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?

Copy link
Owner

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

Copy link
Collaborator Author

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?

Copy link
Owner

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)
Copy link
Collaborator Author

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.

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 4, 2021

I don't get why CI failed. Package.swift is not part of the build process run by CI currently.

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 8, 2021

@krzysztofzablocki Is there something I can do to push the PR forward?

@krzysztofzablocki
Copy link
Owner

@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

@krzysztofzablocki
Copy link
Owner

@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?

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 13, 2021

Would you mind taking a look at those 2 things?

Yes, I'll investigate these issues.

@krzysztofzablocki
Copy link
Owner

@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

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 13, 2021

There was compilation issue with SourceryLibTests target, but I don't see any test failing on my machine.

that step will have to be manual, we can put it in rake,

That step is a part of Rakefile already, isn't it? task :generate_internal_boilerplate_code

@krzysztofzablocki
Copy link
Owner

@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

@SourceryBot
Copy link

1 Warning
⚠️ Big PR

Generated by 🚫 Danger

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 13, 2021

take a look there is a script call there that generates it

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.

@krzysztofzablocki
Copy link
Owner

@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

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 13, 2021

@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 :)

@krzysztofzablocki
Copy link
Owner

@HeMet that's fine I can do it, thanks for contributing this 🙇

@HeMet
Copy link
Collaborator Author

HeMet commented Apr 13, 2021

@HeMet that's fine I can do it, thanks for contributing this 🙇

Thanks for the great tool :)

@krzysztofzablocki
Copy link
Owner

included in #951

@HeMet HeMet deleted the spm-tests branch May 3, 2021 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants