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

[Feature request] Ability to build only one dependency #610

Closed
NachoSoto opened this Issue Jul 12, 2015 · 35 comments

Comments

Projects
None yet
@NachoSoto
Contributor

NachoSoto commented Jul 12, 2015

Apologies if this is already possible, I couldn't figure out a way.

To add a new dependency I would love to be able to do this:

  • Specify new dependency X/Y in Cartfile.
  • carthage update --no-build.
  • carthage build x/y.

Right now we have no choice but building all the existing dependencies again, which can be time consuming.

Thanks ⭐️

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 12, 2015

By the way I'd love to tackle this myself if you guys agree this is useful!

@Adlai-Holler

This comment has been minimized.

Adlai-Holler commented Jul 13, 2015

+1

1 similar comment
@pcantrell

This comment has been minimized.

Contributor

pcantrell commented Jul 14, 2015

+1

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 14, 2015

Right now we have no choice but building all the existing dependencies again, which can be time consuming.

The builds are taking a long time even though they've already been built at that revision?

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 14, 2015

Yeah, carthage build rebuilds everything. Is that not supposed to happen?

@pcantrell

This comment has been minimized.

Contributor

pcantrell commented Jul 14, 2015

Yes. Build with no changes:

$ time carthage build
*** xcodebuild output can be found in /var/folders/ct/_03srt6h8xj44m00r6bfmd400000gn/T/carthage-xcodebuild.ocjJ3M.log
*** Building scheme "Alamofire iOS" in Alamofire.xcworkspace
*** Building scheme "Alamofire OSX" in Alamofire.xcworkspace
*** Building scheme "InAppSettingsKitFramework" in InAppSettingsKit.xcworkspace
*** Building scheme "Mixpanel" in Mixpanel.xcodeproj
*** Building scheme "Siesta" in Siesta.xcodeproj

real    0m24.019s
user    0m22.824s
sys 0m3.995s

~5s apiece is pretty painful when iterating on changes to a dependency.

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 14, 2015

I'd like to look into why this is so slow before adding a workaround.

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 14, 2015

Is Carthage supposed to completely skip building or are you surprised that Xcode takes that long to recompile when everything is already built?

If it's later, I wouldn't rely on that. Swift incremental compilation is pretty much non-existing.

As to the former: how could Carthage know which revision each of the .frameworks in the Build directory corresponds to?

But I'm down for not adding this feature if it's actually unnecessary, I just don't see how yet :)

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 14, 2015

are you surprised that Xcode takes that long to recompile when everything is already built?

I'm surprised, but not that surprised.

@pcantrell

This comment has been minimized.

Contributor

pcantrell commented Jul 14, 2015

Here’s a quick view of where the time goes. Copied below is a process dumping a timestamp every 0.5 seconds in the background, interspersed with the output of carthage build --verbose.

Things to note:

  • The time seems to be spread pretty evenly throughout the build process. There’s not one dependency or one build step that’s the obvious culprit.
  • No actual compilation occurring here, I think? The time seems to be spent just launching processes, opening projects, and checking for changes.

Based on that, I’d say it’s going to be pretty hard to get the 5–10x speedup you’d need to make this feature request unnecessary.

•••••••••••• 16:41:09 CDT 2015
•••••••••••• 16:41:09 CDT 2015
•••••••••••• 16:41:10 CDT 2015
*** Building scheme "Alamofire iOS" in Alamofire.xcworkspace
•••••••••••• 16:41:10 CDT 2015
•••••••••••• 16:41:11 CDT 2015
Build settings from command line:

=== BUILD TARGET Alamofire iOS OF PROJECT Alamofire WITH CONFIGURATION Release ===

Check dependencies
•••••••••••• 16:41:11 CDT 2015

Write auxiliary files
write-file /tmp/Xcode/DerivedData/Alamofire-fzkiieikoiedovbolinkjvotziel/Build/Intermediates/Alamofire.build/all-product-headers.yaml

=== BUILD TARGET Alamofire iOS Tests OF PROJECT Alamofire WITH CONFIGURATION Release ===

Check dependencies

** BUILD SUCCEEDED **

•••••••••••• 16:41:12 CDT 2015
•••••••••••• 16:41:13 CDT 2015
Build settings from command line:

=== BUILD TARGET Alamofire iOS OF PROJECT Alamofire WITH CONFIGURATION Release ===

Check dependencies
•••••••••••• 16:41:13 CDT 2015

Write auxiliary files
write-file /tmp/Xcode/DerivedData/Alamofire-fzkiieikoiedovbolinkjvotziel/Build/Intermediates/Alamofire.build/all-product-headers.yaml

=== BUILD TARGET Alamofire iOS Tests OF PROJECT Alamofire WITH CONFIGURATION Release ===

Check dependencies

** BUILD SUCCEEDED **

•••••••••••• 16:41:14 CDT 2015
•••••••••••• 16:41:14 CDT 2015
*** Building scheme "Alamofire OSX" in Alamofire.xcworkspace
•••••••••••• 16:41:15 CDT 2015
•••••••••••• 16:41:15 CDT 2015
=== BUILD TARGET Alamofire OSX OF PROJECT Alamofire WITH CONFIGURATION Release ===

Check dependencies

Write auxiliary files
write-file /tmp/Xcode/DerivedData/Alamofire-fzkiieikoiedovbolinkjvotziel/Build/Intermediates/Alamofire.build/all-product-headers.yaml

=== BUILD TARGET Alamofire OSX Tests OF PROJECT Alamofire WITH CONFIGURATION Release ===

Check dependencies

** BUILD SUCCEEDED **

•••••••••••• 16:41:16 CDT 2015
•••••••••••• 16:41:16 CDT 2015
•••••••••••• 16:41:17 CDT 2015
•••••••••••• 16:41:17 CDT 2015
•••••••••••• 16:41:18 CDT 2015
•••••••••••• 16:41:18 CDT 2015
*** Building scheme "InAppSettingsKitFramework" in InAppSettingsKit.xcworkspace
•••••••••••• 16:41:19 CDT 2015
•••••••••••• 16:41:19 CDT 2015
Build settings from command line:

=== BUILD TARGET InAppSettingsKitFramework OF PROJECT InAppSettingsKit WITH CONFIGURATION Release ===

Check dependencies
•••••••••••• 16:41:20 CDT 2015

Write auxiliary files
write-file /tmp/Xcode/DerivedData/InAppSettingsKit-gtmydjrabyygvyfjcgblsjrvuute/Build/Intermediates/InAppSettingsKit.build/all-product-headers.yaml

** BUILD SUCCEEDED **

•••••••••••• 16:41:20 CDT 2015
•••••••••••• 16:41:21 CDT 2015
Build settings from command line:

=== BUILD TARGET InAppSettingsKitFramework OF PROJECT InAppSettingsKit WITH CONFIGURATION Release ===

Check dependencies
•••••••••••• 16:41:21 CDT 2015

Write auxiliary files
write-file /tmp/Xcode/DerivedData/InAppSettingsKit-gtmydjrabyygvyfjcgblsjrvuute/Build/Intermediates/InAppSettingsKit.build/all-product-headers.yaml

** BUILD SUCCEEDED **

•••••••••••• 16:41:22 CDT 2015
•••••••••••• 16:41:22 CDT 2015
•••••••••••• 16:41:23 CDT 2015
•••••••••••• 16:41:23 CDT 2015
*** Building scheme "Mixpanel" in Mixpanel.xcodeproj
•••••••••••• 16:41:24 CDT 2015
•••••••••••• 16:41:24 CDT 2015
Build settings from command line:

=== BUILD TARGET Mixpanel OF PROJECT Mixpanel WITH CONFIGURATION Release ===

Check dependencies
•••••••••••• 16:41:25 CDT 2015

Write auxiliary files
write-file /tmp/Xcode/DerivedData/Mixpanel-dgkihzehyzzvxjepeccrpnmubuil/Build/Intermediates/Mixpanel.build/all-product-headers.yaml

** BUILD SUCCEEDED **

•••••••••••• 16:41:25 CDT 2015
•••••••••••• 16:41:26 CDT 2015
Build settings from command line:

•••••••••••• 16:41:26 CDT 2015
=== BUILD TARGET Mixpanel OF PROJECT Mixpanel WITH CONFIGURATION Release ===

Check dependencies

Write auxiliary files
write-file /tmp/Xcode/DerivedData/Mixpanel-dgkihzehyzzvxjepeccrpnmubuil/Build/Intermediates/Mixpanel.build/all-product-headers.yaml

•••••••••••• 16:41:27 CDT 2015
** BUILD SUCCEEDED **

•••••••••••• 16:41:27 CDT 2015
•••••••••••• 16:41:28 CDT 2015
•••••••••••• 16:41:28 CDT 2015
@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 14, 2015

@pcantrell that's a great example, thank you!

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 14, 2015

How often are you rebuilding dependencies and why? We usually update them at most once a week. So an occasional 30 seconds isn't a big deal. (And it usually pales in comparison to the actual build time of any changed dependencies.)

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 14, 2015

Like @pcantrell mentioned, building several times is pretty common when iterating on a particular dependency. Maybe because you're adding commits, or because you're testing different branches, etc.
Compiling all N dependencies every time you want to test a change in 1 is very much a waste of time.

@Adlai-Holler

This comment has been minimized.

Adlai-Holler commented Jul 14, 2015

Agree with @NachoSoto, this build time is insanely slow when iterating dependencies. I just migrated away to CocoaPods+Frameworks because it was so unbearable.

@michaelmcguire

This comment has been minimized.

Contributor

michaelmcguire commented Jul 14, 2015

Is including the dependency using submodules and iterating that way an option? Seems like that is the purpose of submodule support in Carthage. Not that I wouldn't like this feature, but that's how I iterate on dependencies that are being worked on alongside the main application.

@pcantrell

This comment has been minimized.

Contributor

pcantrell commented Jul 14, 2015

@michaelmcguire That feature would need to be configurable on a per-dependency basis to be a suitable substitute. I don’t think it is … right?

@mdiep mdiep added the enhancement label Jul 14, 2015

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 14, 2015

Is including the dependency using submodules and iterating that way an option? Seems like that is the purpose of submodule support in Carthage. Not that I wouldn't like this feature, but that's how I iterate on dependencies that are being worked on alongside the main application.

Yup, that supports my example. But what do you do while you're iterating on them? You need to build the framework to test them inside of the containing application.

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 14, 2015

Submodules aren't configurable on a per-dependency basis. But they should help in this case, which is a nice benefit. But you kinda have to commit and add their projects to your Xcode project. And I don't know that it won't also be slow.

I'm 👍 to letting carthage build take a list of dependencies to build. But carthage update should also get this treatment (a la #218).

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Jul 14, 2015

@mdiep 👍

@pcantrell

This comment has been minimized.

Contributor

pcantrell commented Jul 15, 2015

But what do you do while you're iterating on them?

I was lead to this thread tracking down a discrepancy between how a framework project was building itself in Xcode and how Carthage was building it.

(Short version: not a Carthage issue. Long version: turned out it wasn’t building for a particular architecture, but problem wasn’t manifesting in the usual ways b/c apparently when a Framework Swift class has an Obj-C counterpart in SomeFramework-Swift.h but is missing the arch-appropriate Swift binary, Swift code in the client project will see that Obj-C version, try to use it, and give weird build errors.)

NachoSoto added a commit to NachoSoto/Carthage that referenced this issue Jul 15, 2015

@NachoSoto NachoSoto referenced this issue Jul 15, 2015

Closed

[WIP] Ability to build only one dependency #618

0 of 3 tasks complete
@michaelmcguire

This comment has been minimized.

Contributor

michaelmcguire commented Jul 17, 2015

@pcantrell Sorry, you're right. On this specific project that is not an issue. And as @mdiep mentions, you basically end up needing to add the projects to your Xcode workspace (again not an issue for how I'm using carthage, but understand this isn't necessary how everyone wants to do this)

@evgenyneu

This comment has been minimized.

evgenyneu commented Jul 27, 2015

It this issue related to #218?

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 27, 2015

It this issue related to #218?

Yes, it is, as I mentioned here. 😄

@schickling

This comment has been minimized.

schickling commented Aug 15, 2015

+1

1 similar comment
@bruceflowers

This comment has been minimized.

bruceflowers commented Aug 17, 2015

👍

@lukescott

This comment has been minimized.

lukescott commented Aug 31, 2015

Yes please. Common scenarios for me are:

  • Adding a new dependency
  • Forking a dependency I was using to fix a bug and iterating on those fixes
  • Updating the version of a dependency

I almost never want to rebuild all the dependencies again, which with Swift frameworks seems to happen every time.

@pcantrell

This comment has been minimized.

Contributor

pcantrell commented Aug 31, 2015

Forking a dependency I was using to fix a bug and iterating on those fixes

This!

The fact is that you never need Carthage builds to be fast … until you do.

@AlexanderKaraberov

This comment has been minimized.

AlexanderKaraberov commented Sep 8, 2015

What is the current status of this feature?

@mdiep

This comment has been minimized.

Member

mdiep commented Sep 8, 2015

What is the current status of this feature?

It's currently unimplemented. See #618.

You're welcome to take a crack at it if you like. 😄

@ruipfcosta

This comment has been minimized.

ruipfcosta commented Nov 25, 2015

+1 here. As a workaround I ended up creating a script that builds and merges a single dependency. It's far from being the ideal solution, but at least saves us some time. You can find it at https://github.com/ruipfcosta/carthage-workarounds.

@mdiep mdiep added the help wanted label Nov 26, 2015

ikesyo added a commit to ikesyo/Carthage that referenced this issue Dec 4, 2015

@mpurland

This comment has been minimized.

mpurland commented Dec 4, 2015

+1 For this.

The commit NachoSoto@305451c looks like a reasonable solution

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Dec 4, 2015

Yeah, anybody's welcome to finish up #886 :)

@mpurland

This comment has been minimized.

mpurland commented Dec 4, 2015

@NachoSoto I could give it a shot, what WIP remains on the commit?

@NachoSoto

This comment has been minimized.

Contributor

NachoSoto commented Dec 4, 2015

@mpurland it's listed on the PR :)

@TomLiu

This comment has been minimized.

TomLiu commented Aug 22, 2016

+1 For this.

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