SPM Target Support

[agarrharr]

I'm not sure what the difference is, but I have 2 different projects that are set up in pretty much the same way, with an spm package that has many modules. One of them correctly shows all of the schemes when I run :XcodebuildSetup and the other one does not. I can provide more information if needed.

This one is correct:

And this one only shows 2 schemes:

[wojciech-kulik]

Hmm, the plugin relies on .xcscheme files inside xcodeproj. It looks like Xcode doesn't autogenerate all schemes at once. Clicking on Edit Scheme... and switching between all schemes should generate missing schemes and it should fix the issue.

[agarrharr]

Interesting. Well, for the project that works, I don't have any .xcscheme files in my .xcodeproj...

[agarrharr]

And for the one that doesn't work, it DOES have an .xcscheme... I'm not sure how to click around to make it update...

[agarrharr]

I tried deleting the Countable.xcodeproj/xcshareddata folder and if can now find all of the schemes from my spm module, but of course it can't find the schemes app targets or widget extension (and neither can Xcode obviously).

[notlus]

I ran into this as well. My SwiftPM schemes were in the .swiftpm/xcode/xcschemes folder for the package, with nothing in the xcodeproj folder. Moving the schemes into the xcodeproj folder and updating the project seems to work. Ideally this should not be necessary, given that Xcode seems able to find these schemes.

The other schemes were visible prior to PR 96.

[wojciech-kulik]

Ahhh, so there could be schemes also in .swiftpm/xcode/xcschemes. I didn't know about this path.

[wojciech-kulik]

I will need to investigate it, for now I'm reverting the improvement to find schemes based on generated files. Let me know if it resolves your issue.

[agarrharr]

Thanks, that does fix the issue for me. They all show up now!

[agarrharr]

If you need a project to test with, this is the one that had the problem: https://github.com/agarrharr/Countable

[wojciech-kulik]

I had to revert yesterday's changes because they break other things as now there is no build configuration selection.

I missed yesterday that this problem is generally about SPM packages, currently SPM targets are not supported directly. They break some assumptions of the plugin like running the target or getting build settings (which are not available for SPM packages).

Could you describe what's your use case for selecting a specific SPM module? To build it faster than when using the wrapping app?

If you benefit from using these schemes and it somehow works for you, you can still switch to the previous commit.

[notlus]

For my use-case, this change was a huge benefit. I have a large macOS project with multiple SPM packages. Working in the project involves changing schemes often, depending on what is being worked on. Building the SPM packages via the parent target is very time consuming, and it does not allow me to use the test explorer to run tests for a specific package. This increases the build/test time significantly.

[agarrharr]

Ah, great questions. I don't really need to select them, I was just surprised that they were missing from this list. Technically, it would make it build faster if I was working on one small module at a time.

But if I'm working on a SwiftUI view, I have Xcode in the background and I have an AppleScript that automatically switches to that scheme in Xcode when I save a file so that I can see the SwiftUI preview.

Now that I think about it though, I would need to select one of them to run their tests, right?

[wojciech-kulik]

Currently, tests are supported only via test plans, so if you configure a test plan in your main app that runs tests from specific module you should be able to do that without selecting SPM target.

@notlus for now you can switch to specific commit if this solution worked for you. But keep in mind that build configuration detection doesn't work there, so if you use a different build configuration than "Debug" it won't work correctly.

I need to figure out if and how to support SPM packages, basically it's a different flow than for apps. I guess I would have to support two modes xcodeproj/xcworkspace and SPM module with a different set of commands and behaviors.

[agarrharr]

Yeah, so I'm running an app that includes a single module (called AppFeature) from an spm package (called Modules) under "Frameworks, Libraries, and Embedded Content". In that package, AppFeature has a dependency on other modules and an external library. I think you already understand, but I wanted to be clear and a picture is worth a thousand words.

[notlus]

@wojciech-kulik The main project has multiple peer targets (there is no main app), none of which currently have test plans. I will see whether I can add test plans for them, but it seems like each test plan would need to be configured to run the SPM tests.

I also have this issue with sub-projects. The main Xcode project has some dependencies as child Xcode projects and like the SPM schemes, their schemes are not visible. In Xcode, I can select schemes across the projects.

For now, I will either stick with the commit or move the SPM schemes into the xcodeproj location. For the sub-projects, I guess I will have to switch projects, which is not too frequent.

[wojciech-kulik]

I also have this issue with sub-projects. The main Xcode project has some dependencies as child Xcode projects and like the SPM schemes, their schemes are not visible. In Xcode, I can select schemes across the projects.

Ok, this is a bug caused by looking for schemes inside a single xcodeproj. I need to verify if it's just that, if the plugin in general is able to work with other xcodeprojs included. But I think it should work if the scheme is correctly detected.

The main project has multiple peer targets (there is no main app), none of which currently have test plans. I will see whether I can add test plans for them, but it seems like each test plan would need to be configured to run the SPM tests.

If you wrap your main module inside an app project, you can then create a test plan that will include tests from each SPM package, a single test plan. I was using a similar approach in a project where I was working on a modularized application using SPM. We had just a "demo" project to include this package, run tests, and test in general the functionality.