Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
allow frameworks to specify which schemes Carthage should build #1616
By specifying an optional
If present, the
The work involved in evaluating which schemes to build can be substantial due to requiring
Since frameworks are sometimes useful for purposes internal to a repo and not meant to be consumed externally, specifying a subset of schemes to build in
This can also be useful to work around certain Xcode bugs, such as when Xcode considers unit test bundle products to actually be framework products rdar://29407087.
$ time carthage update --platform osx *** Fetching realm-cocoa *** Checking out realm-cocoa at "a772de1626c9e6b3279c508375a539c29c77244c" *** xcodebuild output can be found in /var/folders/np/5y4sgt8x3r13sk7x0n31z_3m0000gn/T/carthage-xcodebuild.JBCzD7.log *** Building scheme "Realm" in Realm.xcworkspace *** Building scheme "Object Server Tests" in Realm.xcworkspace *** Building scheme "RealmSwift" in Realm.xcworkspace carthage update --platform osx 839.58s user 86.48s system 262% cpu 5:52.89 total
$ time carthage update --platform osx *** Fetching realm-cocoa *** Checking out realm-cocoa at "a772de1626c9e6b3279c508375a539c29c77244c" *** xcodebuild output can be found in /var/folders/np/5y4sgt8x3r13sk7x0n31z_3m0000gn/T/carthage-xcodebuild.VXjlfY.log *** Building scheme "Realm" in Realm.xcworkspace *** Building scheme "RealmSwift" in Realm.xcworkspace carthage update --platform osx 499.41s user 45.25s system 238% cpu 3:48.07 total
Unfortunately, Carthage still builds
This was referenced
Nov 29, 2016
That's a nice idea, but orthogonal to this feature. It doesn't address preventing internal-only frameworks from being exposed externally.
For example, Realm uses a framework called
Thanks for the pull request. I always really appreciate when people open a PR instead of expecting maintainers to do all the work.
I do feel a little uncomfortable with this because it opens the door to a lot of additional configuration and complexity—and Carthage has eschewed all configuration. I feel this both on an implementation level (where the codebase needs to be refactored to handle the existing complexity) and conception level (where we'd probably want a larger vision for what configuration we want to allow and how it works).
But I also respect that this is a very pragmatic choice. That's part of why I've let this sit for a couple days before responding. Idealism vs. pragmatism is a hard line to manage.
I noticed that your radar had a response. Have you tried out the solution they gave? Knowing whether that solves the issue at hand seems like the next step.
Same! And this is a better way to spawn a more concrete conversation than by having a hand-wavy feature request issue.
I can appreciate that. However in practice, as a library maintainer with a fairly complex repo structure, I can safely say that conforming to Carthage's expectations has been more of a burden, and needed more refactoring than this simple configuration option involves.
For example, there's no way currently to have internal-only frameworks (like the
If we explicitly controlled which schemes we wanted Carthage to consider building, there would be less of a burden on library maintainers to consider the Carthage implications of adding another framework in their repo, sometimes deeply nested in an
Please keep in mind as well that this file is entirely optional and won't affect the majority of library maintainers with very simple project structures.
As for wanting to explore a more general strategy for configuration, that's a fair argument and I respect if that's the outcome of this. However, it is disappointing. I'd much rather see this implemented with a warning saying that it's a temporary solution until a more comprehensive configuration approach can be designed and implemented. As you can tell, it's also not a feature that will require a high maintenance burden (it's dead simple for this reason), so it could conceivably be preserved even after a different configuration strategy is introduced.
Yes, but that's only a partial solution to one of the motivating factors for this feature (that Xcode behavior). It doesn't address the "internal-only framework" scenario presented above.
This could be a solution to the problem of working with dependencies like https://github.com/aws/aws-sdk-ios. They have lots of scheme and the entire project takes around 30 minutes to compile. Even if as a library consumer I only want to use AWS S3 I need to be build all their services frameworks. Users of AWS iOS SDK that include it via CocoaPods don't have this issue because they can use subspec but this is not an option with Carthage.
Although we can discuss if the way AWS SDK is structure is adequate or not, having the solution that @jpsim propose will make our life easier and will lower the barrier for library maintainers to adopt Carthage.
Do you have any examples of this? Internal frameworks that are part of shared schemes? (The
(Sorry for the delay. But now that ReactiveSwift 1.0 has shipped, I should be able to wrap up this discussion.)
Unfortunately, I don't think that example warrants adding this to Carthage.
This feature brings a fair bit of risk to Carthage. Although the feature itself isn't complicated, the configuration issue could quickly become a large breaking change in the community. If authors start relying on it to hide broken schemes, then we can't break that support.
Given that this is a minor case, has a workaround, and should really be a enhancement request for Xcode, I don't think it's a good idea to accept it. Carthage has to walk a very fine line here. Since the impact and reach are both small, I don't think it's a good idea.
referenced this pull request
Mar 6, 2017
@mdiep i deeply regret you judged the question this way.