As titled, what's the purpose of "--cache-builds" in carthage command line? if missing this, what could happen and what's the benefit to have this?
From docs:
Caching builds
By default Carthage will rebuild a dependency regardless of whether it's the same resolved version as before. Passing the --cache-builds will cause carthage to avoid rebuilding a dependency if it can. See information on version files for details on how Carthage performs this caching.
Note: At this time --cache-builds is incompatible with --use-submodules. Using both will result in working copy and committed changes to your submodule dependency not being correctly rebuilt.
Related
After retagging a git commit I'm no longer able to fetch the package, because SP Manager uses some cache which I can't find and clean. Getting error:
Revision 30c16cab9c718416fee2191ff2ac0b6f91eeb511 for base
remoteSourceControl https://github.com/myUser/myRepo version 1.0.0
does not match previously recorded value
I cleaned all known to me places: local .build folder, SPM caches in Home and Library/Caches folders, DerivedData, removed Package.resolved.
Using Swift 5.7, trying to generate via swift package generate-xcodeproj.
Does anyone know where this cache is?
This one solves the issue for me.
rm -rf ~/Library/Caches/org.swift.swiftpm
rm -rf ~/Library/org.swift.swiftpm
From https://blog.todosobreios.com/solucionar-problemas-de-swift-pacakge-manager-spm/
It depends on whether you're building via Xcode, or directly via swift build.
Xcode keeps its packages in ~/Library/Developer/Xcode/DerivedData/<your project>/SourcePackages/checkouts/.
SPM keeps them in .build/checkouts of the project folder.
In general, you should never change the commit a version tag points to, for precisely the reasons you experienced. The version numbers form the identity of a package version (not a commit hash, hash of the files, or anything like that). All the systems that are made to work with package rely on the notion that equal version number means they're identical. You're invalidating this assumption, and you'll cause bugs all over. Release a new minor version with your fix, instead.
Cocoapods embed a step in the build phase to check if the Pods folder is in sync with the versions in Podfile.lock. This blocks the developer to work with the stale versions of the Pod with the following error:
error: The sandbox is not in sync with the Podfile.lock. Run 'pod
install' or update your CocoaPods installation.
Carthage has Cartfile.resolved, but how is it used to check if the Carthage Builds are fresh vs stale? Is it something that has to be manually enforced via some script?
Afaik the Carthage guides do not mention this topic at all. Usually you will be informed via failing compilation that a certain framework is not found, e.g. if you switched to a new branch where a new feature is implemented that needs framework XYZ. Then you know you have to run carthage bootstrap.
We have a script that runs so fast that you could even place it into the git hooks so it runs automatically after switching branches. The carthage part just cann the following command:
carthage bootstrap --use-ssh --use-xcframeworks --cache-builds
It makes sure carthage is up to date and it is fast since it uses cached builds. Runs fine for several years now.
I'm debugging a memory corruption issue in an iOS application using Carthage for dependency management.
The problem is most likely related to a 3rd party dependency. I've rebuilt the dependency with -configuration Debug but that didn't give me any more data.
What I'd really like to do is compile it with -fsanitize-address which will hopefully pinpoint the exact moment things start going wrong. Unfortunately I don't see how to do this with Carthage. Is this possible?
You can modify the dependency's source code and project in Carthage/Checkouts. Just open it up in Xcode and tweak away to change anything you like. Then do carthage build to update the frameworks in your project.
Just be aware that the next time you do a Carthage update it will blow away any of the mods you've made. Carthage/checkouts only contains exported versions of the dependencies. Not git repos.
I need to downgrade CocoaPods from 0.35.0 to 0.33.1. However, I'm running into problems.
The Situation
It seems during the upgrade from 0.33.1 to 0.35.0, CocoaPods does the following:
Remove the pressumably obsolete Pods.xcconfig file.
Add the files Pods.debug.xcconfig, Pods.release.xcconfig, etc.
Remove the presence of Pods.xcconfig from my project.pbxproj.
Record the presence of Pods.debug.xcconfig etc in my project.pbxproject.
To downgrade the CocoaPods project from 0.35.0 to 0.33.1, I removed the Podfile.lock and Pods/ folder from my project and did a fresh pod install.
CocoaPods successfully creates Pods.xcconfig. However, my project.pbxproj file is untouched. My project doesn't know about the presence of Pods.xcconfig, hence it no longer compiles. The records for Pods.debug.xcconfig etc are still there, even though it is not used in CocoaPods 0.33.1.
The Questions
How can I tell my Xcode project to use Pods.xcconfig?
How can I tell my Xcode project that I no longer use Pods.debug.xcconfig etc?
Is there a known procedure to gracefully downgrade the CocoaPods version of a project?
Thanks!
Your best bet to do this would be to entirely remove CocoaPods from your project (as I described here) and then run pod install with the older version.
On a sidenote to this, downgrading versions of CocoaPods is a bad idea. Before CocoaPods hits 1.0 any breaking changes can be made that may make working with your old version and the specs repo impossible (without cloning an old unsupported version and maintaining it yourself). As you can see now the minimum supported version is 0.32.1. Obviously that won't be changed just for the fun of it but, if possible, I would recommend that you sort out your issues with the newer versions and try to stay on it.
I am working on a project which includes other repositories from Git.
I would like to keep up to date with these repositories. Know what are the latest features, bug fixes etc.
Qu 1) What is the best way to keep up to date with a repository on Git without receiving emails of all issues reported etc?
After this is complete I would like to know the best way to include these into your project. I understand you can copy the source code into the project, but what are cocoapods/sub modules used for? For example, what is the correct way to update your project with the latest changes to that included repository?
Are there any GUIs for either of these methods as opposed to terminal?
Cocoapods is a great way to include other projects in your Xcode project. The Cocoapods project maintains a list of pod spec files for a many open source libraries, which specify where to download the code and how to integrate them into an existing project. As you noted, you'd traditionally have to add a git submodule, manually add the source files to your project, update your build settings, and so forth. Cocoapods takes care of all of this for you.
I'm not sure of a way to track updates for Github projects without also being notified about issues, but Cocoapods can certainly tell you if any of your 'pods' have become outdated. It's then one command to update them to the latest versions. That said, it's generally best practice to 'lock' your external dependencies to a specific version that you know works correctly.
Using Cocoapods
To get started, first install Cocoapods. You then simply need to create a file in your root project directory (the same directory that contains your .xcodeproj file) called Podfile. Inside, you can specify your target OS, and your dependencies:
platform :ios, '5.0'
pod 'AFNetworking', '0.9.1'
pod 'OHAttributedLabel', '0.1.1'
The example above is targeting iOS 5.0, and pulling in the AFNetworking and OHAttributedLabel projects.
Then, in the Terminal, change to your project directory:
> cd path/to/my/project
And run pod install.
> pod install
This will check out the latest version of your dependencies for you. It will also generate you a .xcworkspace file. From now on, when you work on your project, you must open the .xcworkspace, not the .xcodeproj file.
Inside your new workspace, you'll have your existing Xcode project and a new Pods project - this contains all of your third party libraries. Just build and run your app as normal, and the Pods project will also be built and included.
Some other useful Cocoapods commands:
> pod outdated
Will list all dependencies that have an update available.
> pod search query
Will search all known Pod specs for 'query'. Useful for finding new libraries!
Tutorials
Looks like Tutsplus have a nice tutorial on getting started with Cocoapods
There's a free episode of NSScreencast on Cocoapods
GUIs
I'm afraid I don't know of any GUIs for Cocoapods, but there really aren't many Terminal commands that you need to know. It's worth getting comfortable with the command line, as it's such a useful developer tool.
That said, as far as I know, Appcode (Jetbrains' alternative IDE for Objective-C) is planning on adding Cocoapods support in their next update.
Good luck!
James Frost's answer is an excellent explanation of how to work with Cocoapods and their advantages over submodules.
A few important advantages submodules have over Cocoapods are:
submodules are sub-repos - not only does this mean that git and git GUIs implicitly recognize them and more and more support easily working with them, it also means that your dependencies stay connected the wonderful world their git repos, Cocoapods or not, reside in. This means that you are able to collaborate and test changes from within your project, your project usually being the source of inspiration for elaboration of a dependency.
Unfortunately Cocoapods do not maintain this link, to work on a dependency means to clone it from git, outside of the range of Cocoapods.
Edit: It's worth noting that Cocoapods does allow working on a local pod with the path or local fields or even building your own Spec repo but it still isn't as simple a process.
one less tool dependency - as mentioned in the previous bullet, submodules are a function of git and your using git means they are available to you. Any software's adoption of git implies that they will eventually support either all (important) features of git or all features that cover common use cases. Xcode 5 has brought in a basic support for git and GUIs (which are tool dependencies, it's true, but hopefully just dictate how information is surface, git dictates how it works) like Git Tower make working with sub-repos straightforward.
Cocoapods has come a long way and everyday is taking steps to becoming a stable, indispensable tool. However it hasn't yet gotten a nod from Apple and there isn't any reason why Apple won't release a change to Xcode that breaks Cocoapods. Additionally Cocoapods is dependant on Ruby. Aside, considering how much attention and community has been generated around Cocoapods it would be silly for Apple to ignore it.
It's also worth noting that using one does not lock you out of using the other. It might be a headache or it might be what you need, perhaps using Cocoapods for tiny one class libraries or libraries with complex dependancies and submodules for libraries with that you will be interacting with often.