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

Simplify The Build #243

Open
CodaFi opened this issue Sep 20, 2017 · 9 comments
Open

Simplify The Build #243

CodaFi opened this issue Sep 20, 2017 · 9 comments

Comments

@CodaFi
Copy link
Member

CodaFi commented Sep 20, 2017

As of right now, SwiftCheck builds with

  • Carthage
  • CocoaPods
  • Swift Package Manager

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.

@CodaFi
Copy link
Member Author

CodaFi commented Sep 20, 2017

This means we can eliminate the Xcodeproj as well and just ship the workspace.

@felix91gr
Copy link

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?

@CodaFi
Copy link
Member Author

CodaFi commented Sep 20, 2017

I’ve never used Carthage nor CocoaPods, though. Do they even work on Linux?

Not AFAIK.

what did (or do) they have that SPM didn’t (or doesn’t), s.t. they were (are) attractive still?

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.

@CodaFi
Copy link
Member Author

CodaFi commented Sep 20, 2017

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 swift package generate-xcodeproj and some plutil hackery.

@felix91gr
Copy link

Ohh, I see. Nice :)

@akashivskyy
Copy link
Contributor

Please don't drop Carthage support. 😥

@CodaFi
Copy link
Member Author

CodaFi commented Sep 20, 2017

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 swift package generate-xcodeproj then add it as a sub-project.

@broomburgo
Copy link
Contributor

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.

@CodaFi
Copy link
Member Author

CodaFi commented Sep 20, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants