That sounds like a fine idea. 👍

I was just thinking this would be very helpful in cases where the repository owner doesn't include a Xcode project file. I may take a look at implementing this.

Btw, I've documented how to do this manually at https://fuller.li/posts/using-swift-package-manager-with-carthage/ as a proof of concept.

Any plans on implementing this? I'm using some https://github.com/Zewo frameworks, they all appear to use SPM and seem to have good reasons for that. Carthage supporting SPM would be a super useful feature! ❤️

After talking to the SwiftPM team, I don't think it's a good idea for us to rely on the generated Xcode projects.

Can you share the details? Doesn't SwiftPM use the same logic, it obviously doesn't generate the project, but simply compiles all sources, right?

SwiftPM can compile the sources—but not into a .framework that Carthage can use.

To do that, we'd need to use swift package generate-xcodeproj, which generates an Xcode project based on the package. It's been recommended that we not rely on that.

Any reasons why the generated Xcode project cannot be recommended? I understand, the development of SwiftPM is in its infancy.

Still, I managed to use Carthage as usual in a project, for a dependency which is originally a Swift package, and this Swift package itself depends on other Swift packages.

The top dependency has a Swift generated Xcode project which has added a pre-build script which calls swift package fetch in order to get the other dependencies. That is, SwiftPM serves solely as a package manager for the underlying dependencies, while Carthage still builds the binaries as frameworks.

The generated Xcode projects works quite well out of the box. The only modification is the addition of the pre-build script. You can take a look at it, here in this fork. The original project is the awesome Genome package - which also provides a different approach to make this library available for Carthage. The reason why I made a fork was a totally different issue, though.

So, with this positive experience, I think you might give auto-generated Xcode projects a try. ;)
Later, we should be able to just use Swift modules. :)

I agree that unstable solution is better than no solution, right now we're relying on semi-manual approach. For what it's worth, SwiftPM itself is far from stable, not just generated Xcode projects, which will improve no doubt. Perhaps this could take off as experimental feature and evolve with SwiftPM?

Hey guys, I've created a PR(#1945) for this. I hope you guys could review my PR. Thanks!

What's the state of SwiftPM support in Carthage? It seems it's been a long time since anything has been done. Today I wanted to use a project that is built only as a Swift Package, and has no Xcode project. I really don't want to go through the hassle of having to generate an xcode project. Carthage really should support SPM directly (using the SPM library to build the package, and placing the build products in the right place).

Today I wanted to use a project that is built only as a Swift Package, and has no Xcode project.

A bit off topic, but if you are using Xcode 11 you can depend directly on a SPM package, without using Carthage or any other tool.

ref: https://developer.apple.com/documentation/xcode/adding_package_dependencies_to_your_app

I suppose that's a workable solution. Too bad it splits the specification of dependencies into more than one place. I suppose it'll encourage everyone to provide SwiftPM support in their projects, possibly making Carthage and CocoaPods eventually obsolete.

Carthage is a much better solution to dependency management than Cocoapods due to separation of the build process from the workspace/project. I think the way forward on this is to use swift build rather than xcodebuild. Is this possible?
I think that generating an xcodeproj file and using xcodebuild is just hanging onto a system that ought not to exist in any case. And IDE like Xcode is fine for development but should not be required for building. Way back when IDEs came out first Microsoft copped a lot of flak from the UNIX camp for this practice. The idea is that you should be able to build external to the IDE, then generate a IDE project for development, if you need it. However, this is rarely needed by users of third party dependencies (they just want to build it or link to it). SPM in my view does the correct thing by building first and generating a IDE project file later. It's why I believe that this should be adopted going forward.
Referencing swift dependences in Xcode is useful for existing Xcode projects that want to use swift libraries. I don't believe it should be used for anything else and I certainly don't think that it should be adopted as the standard. We should be taking things out of Xcode, not putting them in.