-
Notifications
You must be signed in to change notification settings - Fork 105
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
Simplify The Build #243
Comments
This means we can eliminate the Xcodeproj as well and just ship the workspace. |
SPM ftw! I’ve never used Carthage nor CocoaPods, though. Do they even work on Linux? Also, what did (or do) they have that SPM didn’t (or doesn’t), s.t. they were (are) attractive still? |
Not AFAIK.
Swift PM was the latecomer for our build system, which was originally based on Carthage because we had a weird dependency structure (I eliminated that dependency structure a while ago). In addition, SwiftPM didn't support custom target layouts and test-only dependencies. Now that the package manager has matured, we can describe our entire build with it. |
The biggest tradeoff here is that we are dropping explicit builds for iOS and tvOS (watchOS still doesn't support testing targets). I suspect, tho, that we can still recover this with |
Ohh, I see. Nice :) |
Please don't drop Carthage support. 😥 |
If we did you could add the framework as a submodule tracked by carthage, it just won't build a framework automatically. You'll need to generate the Xcode project with |
I agree that the state of the build systems is messy, and if the goal is keeping only one, I'd too go with Swift PM. Unfortunately dropping Carthage support (for SwiftCheck and in prospect for all the typelift libraries) is going to be extremely painful for iOS developers: Carthage was literally a godsend for iOS devs that didn't want to lose control of their project to CocoaPods, and has become basically a given for many. |
We won't be dropping iOS support, we'll just be dropping Carthage's iOS support. I don't intend to do this now, but when and if we come up with a satisfactory solution that keeps our per-platform builds working - or if Apple decides to allow multiple platforms in one package def - we will be switching |
As of right now, SwiftCheck builds with
And maintains a linear number of build scripts and package definitions for each.
This Is Absurd
We need to commit to just SwiftPM now that we're building against Swift 4.0. My understanding is that a PodSpec can still be provided with the repo even with that kind of change, so this means we're just dropping Carthage on the floor.
This change will not be made without some reasonable form of migration in place.
The text was updated successfully, but these errors were encountered: