Remove shared example layouts scheme so as not to be built by carthage #131
Conversation
|
I think that makes sense to remove from Carthage dependency. @nicksnyder Do you have any objection? |
|
I am not a fan of this. We shouldn't have to hide schemes just to prevent Carthage from building stuff. Are you sure that Carthage does not provide a way to depend on a specific scheme? |
|
It does not, AFAIK. You can only filter by platform.
If necessary we will maintain our own fork and hide it there.
May I ask, what is the rational behind having example layouts as a shared
scheme?
…On Thu, Apr 20, 2017 at 10:02 AM Jingwei Huang ***@***.***> wrote:
@nicksnyder <https://github.com/nicksnyder> @stowy
<https://github.com/stowy> FYI, Carthage/Carthage#728
<Carthage/Carthage#728>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#131 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFpnFJmTDYo6Wwv3zjPxeqPVX1n8Oj0qks5rx4-ngaJpZM4NCBwV>
.
|
|
If Carthage just blindly builds all schemes, that is Carthage's fault. I am kind of surprised they don't want to fix this.
Probably the best solution.
When developing an example layout it is nice to be able to build that independently.
How much time does it take? ExampleLayouts is really small so it should be very fast to compile. Does Carthage also build the sample app? |
It takes around 30 seconds to build.
No, it doesn't build application target. |
In what environment? How are you measuring? It takes <8 seconds to build on my early 2015 dual core macbook pro |
|
I tested 3x times and the average is 38 seconds to build I tested on MacBook Pro (Retina, 15-inch, Mid 2015), 2.5 GHz Intel Core i7, 32G RAM
|
|
I agree that it is a waste of time to build ExampleLayouts. Not only is Carthage unnecessarily building ExampleLayouts-iOS when it shouldn't, but LayoutKit itself is getting built twice: once when LayoutKit-iOS is built and a second time because ExmapleLayouts-iOS depends on it (the build isn't cached). I think this waste of time is caused by Carthage though. Library maintainers should be free to share whatever schemes they please. If Carthage wants to piggy back on shared schemes, then it should provide a way to make schemes as hidden from Carthage consumers. |
|
@jingwei-huang1 you may find the @nicksnyder you may consider attaching a prebuilt binary framework to your GitHub releases, which could avoid building at all for matching Swift versions. |
|
@dcaunt Thanks for the pointer to prebuilt artifacts doc.
@stowy For a given version of Swift we can provide a pre-built binary. I would prefer this solution. |
|
@nicksnyder great, that sounds like a good solution, thanks. We can close this PR in that case. Thanks @dcaunt and @jingwei-huang1 for the extra input 👍 |
|
So the release checklist will be updated to include instructions for adding the pre-build binary? Who is the best person to do that? |
|
The linked instructions include steps for configuring Travis to do it automatically |
@nicksnyder I would like to remove ExampleLayouts from the shared schemes, since it builds when you specify LayoutKit as a Carthage dependency, which is undesirable as it takes additional build time.
If we are to have LayoutKit, which is swift-based, as a dependency, when building on ci without a pre-built artifact, we would like to minimize the build time for swift dependencies.
Swift dependencies can't really be stored as pre-built artifacts AFAIK due to the lack of ABI stability.