Add support for Swift Package Manager only projects #1945

devxoul · 2017-05-20T18:29:48Z

Background

Swift Package Manager doesn't have Xcode dependency so the library authors can distribute their code without Xcode project files. Already there are many projects that don't have Xcode project files in their Git repository (e.g. ReactorKit). One of the most important design goal of Carthage is to reduce the responsibility of Xcode:

Ultimately, we created Carthage because we wanted the simplest tool possible—a dependency manager that gets the job done without taking over the responsibility of Xcode, and without creating extra work for framework authors.

This PR makes Carthage to have less dependency of Xcode by supporting SPM-only libraries.

Summary

Run swift package generate-xcodeproj before each build processes if the dependency doesn't have both .xcodeproject and .xcworkspace butPackage.swift.
Add a fixture for testing SPM-only library.

Related Issues

Resolves Supporting SwiftPM Generated Xcode Projects #1226

devxoul · 2017-05-27T10:31:02Z

@ikesyo, could you please review this PR when you're available? Thanks!

PS: I'm not sure why the test is failing. It fails just after rebasing master.

mdiep · 2017-05-27T21:43:46Z

Last time I talked to the SwiftPM folks, it was suggested that we not rely on this functionality. I'll try to find someone at WWDC to talk to about this.

devxoul · 2017-05-28T07:50:03Z

@mdiep, I'm curious why we should not rely on that function. I think unstable solution is better than no solution. Even we can offer this functionality as a beta (or with a explicit flag) and change the implementation future. I hope I could distribute my code-only libs to Carthage without Xcode :)

mdiep · 2017-05-28T14:30:25Z

I think unstable solution is better than no solution.

I don't think that's true.

An unstable solution would likely:

Greatly increase the support load for Carthage. Which would decrease the time available for development.
Remove the incentive for project creators to add proper Carthage support—which will hurt everyone when/if this function breaks

devxoul · 2017-05-28T15:07:25Z

You might be true if the swift package generate-xcodeproj is definitely unstable, but I can't understand why it is unstable :)

Anyway, do you have any suggestion for adding Carthage support to existing SPM-only project?

mdiep · 2017-05-28T17:14:03Z

I think generating the xcodeproj is a fine way to start Carthage support. Generate, share the scheme, and check it in, and you should be good to go.

devxoul · 2017-05-28T17:25:33Z

@mdiep You mean the Xcode project from Xcode.app not by swift package generate-xcodeproj?

mdiep · 2017-05-28T17:40:49Z

No, I mean generating with swift package generate-xcodeproj, sharing the scheme, and then checking it in.

devxoul · 2017-05-28T17:55:55Z

Hmm, I'm confused because you just said that swift package generate-xcodeproj is unstable so we should not rely on it. 🤔🤔🤔 Is there any difference between doing that on Carthage and each lib? Maybe the schemes?

mdiep · 2017-05-28T18:18:54Z

It's not guaranteed to work for all projects. But if it's a fine starting place. If it works out of the box for your project, great! This acts as a QA step for projects—they have to confirm that the generated project works.

devxoul · 2017-05-28T19:00:10Z

Thanks for your kind reply. I hope we could find a better solution 👍 Feel free to close or keep this PR open.

devxoul · 2017-06-13T13:23:54Z

@mdiep, was there any updates on WWDC? :)

mdiep · 2017-06-16T13:06:17Z

After talking to someone from the SwiftPM team, I'm tentatively on board with adding support for this. It will require some testing. I'll try to play with this soon, but it will need to be a lower priority than some of my other OSS maintenance.

mdiep

This will need some documentation updates as well.

mdiep · 2017-06-16T13:06:44Z

Source/CarthageKit/Project.swift

+	public func generateSwiftPackageManagerXcodeProjectIfAvailable(forDependencyAt dependencyPath: String) -> SignalProducer<(), NoError> {
+		let files = (try? FileManager.default.contentsOfDirectory(atPath: dependencyPath)) ?? []
+
+		let hasXcodeProjectFile = files.lazy.filter { $0.hasSuffix(".xcodeproj") || $0.hasSuffix(".xcworkspace") }.first != nil


Instead of doing foo.lazy.filter { ... }.first, you should be able to do foo.first { ... }.

mdiep · 2017-06-16T13:07:16Z

Source/CarthageKit/Project.swift

+		let hasPackageFile = files.lazy.filter { $0 == "Package.swift" }.first != nil
+		guard hasPackageFile else { return .init(value: ()) }
+
+		let task = Task("/usr/bin/swift", arguments: [ "package", "generate-xcodeproj" ], workingDirectoryPath: dependencyPath)


This should definitely have a project event that gets printed to the console.

Generating an Xcode project to the dependency directory makes it dirty so that should be avoided. You should generate a project to a temporary directory.

@ikesyo For a temporary directory, would $TMPDIR be preferred?

mdiep · 2017-06-16T13:08:17Z

Tests/CarthageKitTests/ProjectSpec.swift

+					.flatten(.concat)
+					.ignoreTaskData()
+					.on(value: { (project, scheme) in
+						NSLog("Building scheme \"\(scheme)\" in \(project)")


Can you remove this log from the test?

devxoul · 2017-06-16T14:16:04Z

@mdiep, Sounds cool. I found that SPM generated project can cause a problem if the library has dependencies. I'll update this PR soon with more specific tests. Thanks!

ikesyo · 2017-06-16T15:13:58Z

Source/CarthageKit/Project.swift

+	public func generateSwiftPackageManagerXcodeProjectIfAvailable(forDependencyAt dependencyPath: String) -> SignalProducer<(), NoError> {
+		let files = (try? FileManager.default.contentsOfDirectory(atPath: dependencyPath)) ?? []
+
+		let hasXcodeProjectFile = files.lazy.filter { $0.hasSuffix(".xcodeproj") || $0.hasSuffix(".xcworkspace") }.first != nil


This will not be sufficient––Carthage allows having Xcode projects or workspaces in any subdirectories so you should need to check the dependency directory recursively.

ikesyo · 2017-06-16T15:15:44Z

Source/CarthageKit/Project.swift

+		let hasPackageFile = files.lazy.filter { $0 == "Package.swift" }.first != nil
+		guard hasPackageFile else { return .init(value: ()) }
+
+		let task = Task("/usr/bin/swift", arguments: [ "package", "generate-xcodeproj" ], workingDirectoryPath: dependencyPath)


Generating an Xcode project to the dependency directory makes it dirty so that should be avoided. You should generate a project to a temporary directory.

ikesyo · 2017-06-16T16:18:39Z

Another viewpoint: Deployment target settings of a generated Xcode project are not set for iOS, tvOS, and watchOS (macOS is set to 10.10). That means that the actual deployment target determined for each platforms will be its latest SDK (iOS 10.3, tvOS 10.2, watchOS 3.2 in Xcode 8.3.x). So actually the generated project should be useless without any modification (are your application targeting iOS 10.3 only? 🙂).

I'm still reluctant to add this feature.

mdiep · 2017-06-16T16:59:42Z

Another viewpoint: Deployment target settings of a generated Xcode project are not set for iOS, tvOS, and watchOS (macOS is set to 10.10). That means that the actual deployment target determined for each platforms will be its latest SDK (iOS 10.3, tvOS 10.2, watchOS 3.2 in Xcode 8.3.x). So actually the generated project should be useless without any modification (are your application targeting iOS 10.3 only? 🙂).

When talking to the SwiftPM folks, this did seem like a potential issue. I'm not super knowledgable about it, but they mentioned the idea of passing an .xcconfig file when building to set those flags.

I guess any SwiftPM project wouldn't depend on the SDK, so Carthage could hardcode the oldest viable option?

I'm still reluctant to add this feature.

I think you're more knowledgable about this than I am, so definitely speak up if you think something is a bad idea.

ikesyo · 2017-06-16T17:11:06Z

When talking to the SwiftPM folks, this did seem like a potential issue. I'm not super knowledgable about it, but they mentioned the idea of passing an .xcconfig file when building to set those flags.

I guess any SwiftPM project wouldn't depend on the SDK, so Carthage could hardcode the oldest viable option?

Sounds reasonable to me. We can pass --xcconfig-overrides option to swift package generate-xcodeproj command which will be better than overriding on building.

devxoul · 2017-06-16T18:30:42Z

We can set deployment version by providing a xcconfig and bundle version by modifying an Info.plist. Currently I'm archiving SPM generated xcodeproj as following:

I think I can do similar with Swift but I'm not sure this would be the best solution 🤔

olbrichj · 2017-08-09T11:55:11Z

Is there any update on this one?

mdiep · 2017-08-09T12:13:02Z

There's some unaddressed feedback above.

mxcl · 2019-01-30T17:12:19Z

The generated xcodeproj has all platforms available as build targets, I spoke to @aciidb0mb3r about it and he said that the platform specification in Package.swift files doesn't actually restrict the platforms it merely allows deployment targets to be set. So this idea is bunk, we still need xcconfig files otherwise the generated project will almost certainly fail to build since it will pretend that it can build for eg. tvOS and then fail if it (likely) doesn't support tvOS actually.

Edit: well the deployment targets ARE set correctly. So maybe the trick is to only build for the platforms that the target project sets? Not fool-proof, but perhaps sufficient?

mxcl · 2019-02-01T15:52:56Z

Hey everyone, so I've been thinking about this a lot and here is my current plan:

Only support this if the toolchain is a Swift 5 toolchain
Only support this if the package provides a Swift 5.0 or higher tool-version manifest
Generate the xcodeproj
Only build for platforms explicitly declared in the manifest

I will begin work on this, this weekend, so if there are concerns with my approach, please speak up!

Thanks for the help 🙏

mxcl · 2019-02-12T21:55:39Z

As an update here I have submitted a PR to SwiftPM to get the platform information from the dump-package command. I hope it will be released with Xcode 10.2, but if not we can figure out another way.

mxcl · 2019-03-07T16:19:25Z

Update: the dump-package changes are finally in Xcode 10.2-beta4 so I will attempt to finish the patch.

rynecheow · 2019-03-28T11:44:57Z

May I ask how are we doing with this PR?

mxcl · 2019-03-28T15:36:00Z

I am unlikely to find time for this in near future, here’s my progress though:

https://github.com/mxcl/Carthage/tree/spm

JonasVautherin · 2019-03-28T19:03:57Z

@mxcl: Would you mind elaborating a bit on what would need to be done on your PR?

mxcl · 2019-03-28T22:19:25Z

I believe the remaining part is parsing dump-package and setting deployment targets, nothing else.

ollieatkinson · 2019-04-16T15:47:36Z

From what I can see these are the following settings which would need to be added to the generated Xcodeproj:

IPHONEOS_DEPLOYMENT_TARGET = 8.0
SUPPORTED_PLATFORMS = iphonesimulator iphoneos
SDKROOT = iphoneos
DEFINES_MODULE = YES
MODULEMAP_FILE = $(PACKAGE_NAME).xcodeproj/GeneratedModuleMap/$(TARGET_NAME)/module.modulemap

Steps:

Run swift package dump-package, grab the following information:

"platforms" : [
    {
      "platformName" : "ios",
      "version" : "8.0"
    }
],

Create an xcconfig file inside of the temporary with the values above, transformed appropriately
When generating the xcodeproj pass --xcconfig-overrides path/to/tmp/config.xcconfig

If the project does not specify platform information, I'm guessing we should just fail out - but some steer on that from the core contributors would be good.

If the above sounds reasonable, I can give it a go - but I will hang fire until I get some feedback.

Edit: Have I found a further complication?

Unless I'm missing something, I think we will also need to generate an xcodeproj for each platform we want to build for because only one target is generated by SwiftPM.

thedavidharris · 2019-06-27T01:49:31Z

Edit: Have I found a further complication?

Unless I'm missing something, I think we will also need to generate an xcodeproj for each platform we want to build for because only one target is generated by SwiftPM.

I don't think so, SUPPORTED PLATFORMS and the OS flags should be enough. https://davedelong.com/blog/2018/11/15/building-a-crossplatform-framework/ describes a way of doing this, then when the platforms are targeted it'll pick up the right version of everything.

@ollieatkinson @mxcl any continued work on this? I may be able to help pick it up, as we currently are writing a bunch of SPM modules internally that need Carthage integration for some of our current apps and support both is a bit of a pain for the interim, so would be interested in helping out on this

thedavidharris · 2019-07-10T15:56:02Z

So, looks like there's an edge case that won't make this workable for us, and that's when an SPM project has dependencies that are also Carthage dependencies by the consuming project. Probably won't take this on anymore myself, as I don't think there's any solution to that problem :/

Sajjon · 2019-11-25T09:17:57Z

@devxoul Hey! What is the status of this PR? It is open since 2017. It would be great if Carthage could build Swift Packages :)

JonasVautherin · 2019-12-18T00:19:56Z

@thedavidharris: I understand the issue of having common dependencies between SPM and Carthage, and that's an issue because Carthage is not designed to deal with that manually.

However, it is currently a problem that libraries that only support SPM cannot be used in a Carthage project.

Do you think there could be a way to deal with that problem by leveraging xcodegen? I'm thinking of a way to generate an xcodeproj that would embed SPM packages, while allowing to ignore SPM dependencies that also come from Carthage. Would be fine if it requires some manual work to get the setup correct, as it would allow Carthage users to benefit from SPM-only libraries.

Or do you think that it's not worth it and SPM will quickly take over now that it is embedded in Xcode?

scosman · 2023-04-20T17:24:34Z

Anyone trying to accomplish this, I got it running fairly easily with another tool in combination with Carthage. No need to manually maintain xcodeproj files, as this can generate them from your Package.swift.

Install XcodeGen tool: https://github.com/yonaskolb/XcodeGen
Add a project.yml file for the framework. Can be quite simple, but need to point to your Sources directory, include info section (just a path to generate Info.plist to), and include schemes: {} sections. Sample: file https://github.com/CriticalMoments/CriticalMoments/blob/ebfe2ead8783dd43b94d89b135225a0b2e12b80e/ios/project.yml
Generate the project files Carthage needs with xcodegen generate --spec ./project.yml
Then Carthage works: carthage build --no-skip-current --use-xcframeworks

This was referenced May 20, 2017

Supporting SwiftPM Generated Xcode Projects #1226

Open

Carthage: no shared scheme ReactorKit/ReactorKit#17

Closed

devxoul added 3 commits May 27, 2017 19:28

Add Swift Package Manager support

a7ae5c7

Add fixture for SPM only framework test

695526d

Add test for SPM only framework

7ec5e54

devxoul force-pushed the spm branch from ee14b72 to 7ec5e54 Compare May 27, 2017 10:29

mdiep reviewed Jun 16, 2017

View reviewed changes

ikesyo reviewed Jun 16, 2017

View reviewed changes

ikesyo requested changes Jun 16, 2017

View reviewed changes

yonaskolb mentioned this pull request Aug 9, 2017

Support Carthage tuist/XcodeProj#41

Closed

mxcl mentioned this pull request Jan 27, 2019

[Feature request] Carthage support mxcl/Path.swift#17

Open

sbarow mentioned this pull request Feb 14, 2019

Carthage not working for 0.5.1 & 0.6.0 grpc/grpc-swift#329

Closed

ollieatkinson mentioned this pull request Mar 8, 2019

Add support for tuist/xcodegen projects #2722

Closed

pixlwave mentioned this pull request May 5, 2019

Xcode projects? mxcl/AppUpdater#7

Closed

Saik0s mentioned this pull request Nov 18, 2019

Add XcodeGen support #714 SwifterSwift/SwifterSwift#761

Closed

7 tasks

yonaskolb mentioned this pull request Nov 24, 2019

SwiftPM dependencies don't link their required dependencies yonaskolb/XcodeGen#708

Closed

elitalon mentioned this pull request Mar 14, 2020

Carthage supports davedelong/time#9

Open

iby mentioned this pull request May 6, 2020

Carthage is failing to bootstrap and update 0.7.2 mrackwitz/Version#49

Open

jimmyhoran mentioned this pull request Nov 8, 2020

Swift Package SafetyCulture/PleaseAllow-iOS#16

Closed

TTOzzi mentioned this pull request Sep 30, 2021

프로젝트 생성 및 세팅 depromeet/Archive_iOS#2

Closed

Add support for Swift Package Manager only projects #1945

Are you sure you want to change the base?

Add support for Swift Package Manager only projects #1945

Conversation

devxoul commented May 20, 2017 • edited

Background

Summary

Related Issues

devxoul commented May 27, 2017 • edited

mdiep commented May 27, 2017

devxoul commented May 28, 2017

mdiep commented May 28, 2017

devxoul commented May 28, 2017 • edited

mdiep commented May 28, 2017

devxoul commented May 28, 2017

mdiep commented May 28, 2017

devxoul commented May 28, 2017

mdiep commented May 28, 2017

devxoul commented May 28, 2017 • edited

devxoul commented Jun 13, 2017

mdiep commented Jun 16, 2017

mdiep left a comment

Choose a reason for hiding this comment

mdiep Jun 16, 2017

Choose a reason for hiding this comment

mdiep Jun 16, 2017

Choose a reason for hiding this comment

ikesyo Jun 16, 2017

Choose a reason for hiding this comment

yhkaplan Oct 13, 2018

Choose a reason for hiding this comment

mdiep Jun 16, 2017

Choose a reason for hiding this comment

devxoul commented Jun 16, 2017 • edited

ikesyo Jun 16, 2017

Choose a reason for hiding this comment

ikesyo Jun 16, 2017

Choose a reason for hiding this comment

ikesyo commented Jun 16, 2017

mdiep commented Jun 16, 2017

ikesyo commented Jun 16, 2017

devxoul commented Jun 16, 2017 • edited

olbrichj commented Aug 9, 2017

mdiep commented Aug 9, 2017

mxcl commented Jan 30, 2019 • edited

mxcl commented Feb 1, 2019

mxcl commented Feb 12, 2019 • edited

mxcl commented Mar 7, 2019 • edited

rynecheow commented Mar 28, 2019

mxcl commented Mar 28, 2019

JonasVautherin commented Mar 28, 2019

mxcl commented Mar 28, 2019

ollieatkinson commented Apr 16, 2019 • edited

thedavidharris commented Jun 27, 2019

thedavidharris commented Jul 10, 2019

Sajjon commented Nov 25, 2019

JonasVautherin commented Dec 18, 2019

scosman commented Apr 20, 2023

devxoul commented May 20, 2017 •

edited

devxoul commented May 27, 2017 •

edited

devxoul commented May 28, 2017 •

edited

devxoul commented May 28, 2017 •

edited

devxoul commented Jun 16, 2017 •

edited

devxoul commented Jun 16, 2017 •

edited

mxcl commented Jan 30, 2019 •

edited

mxcl commented Feb 12, 2019 •

edited

mxcl commented Mar 7, 2019 •

edited

ollieatkinson commented Apr 16, 2019 •

edited