Over time, I have a lot of older targets in my drake cache (current==FALSE under drake_history()). I've renamed many of my targets over time, so I'm left with targets in drake_history() which are current==TRUE, however they're not in my current drake plan.
Is there a way to clean up the cache to get rid of all older targets (to save space), and also remove any targets (current or otherwise) which are not in my plan?
Rahul
Yes, drake's cache has garbage collection. To remove old targets and save space, you can call drake_gc() or drake_cache()$gc().
Related
Swift Package Manager got a new feature in Xcode 12.5:
Swift Package Manager caches package dependencies on a per-user basis, which reduces the amount of network traffic and increases performance of dependency resolution for subsequent uses of the same package. If needed, you can disable cache use in xcodebuild by using the new -disablePackageRepositoryCache flag. (72204929)
I would like to know where this is cached. Maybe we can use this to easily cache those dependencies in continuous environments.
I want to know what is the difference of this change to the behavior before since before there was already a cache folder in DerivedData. So what is the new thing here?
Xcode 12.5 release notes appear to be referring to ~/Library/Caches/org.swift.swiftpm/.
I have been working in iOS project. Regarding Xcode Derived Data folder whose contents are generated by build system, there are many Stackoverflow posts, i.e. how to remove derived data folder or is it safe to remove derived data folder, etc. but there is none which I am looking for. My question is to know when should I delete the derived data folder and when should I not? In other word, in which conditions this derived data becomes non reusable and why? Are those derived data become stale after resource or configuration change of the project or anything else? I often see many issues are resolved after deleting derived data but we often do not try to know the root cause of the issues.
Can I simply say, until the .xcodeproj file change, the derived data can be reused safely?
Background of the question: In my project, I have a proof build system so that every CLs need to pass the proof build before getting merged to remote branch. So I need to know the risks to architect when I should (or should not) reuse the derived data folder to make the proof build system performant.
Sadly, deleting DerivedData has become the catch all to try and remedy build issues. As you already know, you can delete the DerivedData at any point in time with no issues (unless of course you were building). The nuances as to when it is safe is a little more complicated. In practice I have generally found that significant changes in the code between builds can have issues. Likewise, changing Xcode versions can also have issues. The key words here being can, which does not mean it will.
I do not believe there is any definitive means of knowing when to purge, which is why I think you find most people generally asking "did you remove DerivedData" as one of the first questions when someone has a build problem.
IMHO, I think there is some subtle caching that Xcode does within DerivedData, as I've had build failures in weird situations I could not trace. I would not be surprised if Xcode has some subtle bug related to this caching. In general, I only trusted a command line delete of the project's DerivedData. And if I was extra careful, I'd also purge any associated libraries/frameworks as well as the ModuleCache (in DerivedData). There is also some voodoo in the /var/folders. Not sure if this is still the case, but I have found myself surgically nuking stuff there. Yeah, bad. But I'm also the kind of person that has been known to edit the project.pbxproj file to fix it, so I guess I throw caution to the wind.
Let me ask you this question. What is more important? "bullet-proof" or build times? I've been roped into maintaining or upgrading the build systems for a few apps. I've always done everything as a clean build. This always was fresh pull from source control and then having a defined DerivedData within the workspace (these were Jenkins builds and was configured to use a clean workspace). This pretty much avoided build issues related to needing to remove DerivedData. I've seen way too many strange issues occur due to some Xcode voodoo. It is far better to not add red herrings if you have a build error.
If you do find that the builds as well as any tests needed are taking too long, you can start to devise other strategies to help make it more manageable. This becomes very project dependent. For example on a project I was working on, I moved all libs to pre-built versions. For some reason, they had it setup where they had to build all the 3rd party libs (like openssl) during the build process. This also means that the devs incurred this build penalty the first time they built or any time the cleaned.
You might want to clean derived data when -
When you pull code from remote repository because it might contain new/deleted file which you might be using in other module/project.
Consider there are two project (say ProjectA and ProjectB) in your workspace.
1) You already build your app and their derived data is available.
3) Now consider there is reference to some `Class` of Project A in Project B. You have used static function form ProjectA classes.
2) Now you pull code from remote repo and it contains changes for Project A only.
3) In this pull, the used static function form ProjectA gets deleted.
3) When you build app again, only Project A gets complied again but not Project B because it has no code change. Inshort, when there is change in code XCode complies that module again not complete app.
4) Now you will you get build issue as dependencies are not correct now. Project B has no idea what happened.
5) So in this case, you should clean derived data.
Correct code coverage report.
Code coverage reports into the default derived data directory located at ~/Library/Developer/Xcode/DerivedData.
You can clean code coverge report form DerivedData and regerate it again.
Please correct me if i am wrong. This is as per my understanding.
Will update this answer if i found more reasons.
Derived data can take up significant space too. Derived data is generated during each app build process. Derived data contains intermediate build results, generated indexes, that help speed up build time.
You can think of derived data as cached data/image in web browser, most of the time web browser will auto-save the data/image into your hard disk when you first browse a web page, and the next time you visit the same web page, the page load speed is faster as web browser will use the cached data /image in hard disk.
Few cases I would like to mention when you should delete derived data:
I faced this issue many times that Xcode’s debugger stop working
suddenly so resolve this issue I delete derived data and it start
working fine.
Whenever you are facing issues in building project then it is better to delete derived data and build again.
Deleting derived data causes minor delay in building project for the
first time but it deletes all old settings for the project.
Deleting derived data boost up your system’s performance as it holds lots of memory space which may not needed since very long.
And last but not least for error that are not logical sometimes,
all you have to do is just delete Derived data & error is gone.
Happy to help!
When can i delete the derived data ?
If you happen to have multiple build agents running on multiple machines (either physical or virtual), then each of those agents should do it’s own cleanup.Cleaning derived data might increase the time of first build for each project next day, but it’s a minor drawback. You will also claim free space back by killing DerivedData’s huge appetite. A practical advice to take home - clean Xcode Derived Data on regular basis on your CI box(es),You could create a cron job to do that, make it run some time after midnight and execute this simple shell command.
rm -rf /Users/username/Library/Developer/Xcode/DerivedData/*
For daily use on your development machine create a type alias in your bash profile.
typealias xcode-clean-derived="rm -rf /Users/i4niac/Library/Developer/Xcode/DerivedData/*"
Source :
https://mgrebenets.github.io/mobile%20ci/2015/02/01/xcode-derived-data
Currently my project relies on many pods, adding pods makes my binary bigger, I'd like to inspect the pods I linked to and see which of them is the biggest, so that I could know which of them I should remove.
Any Idea?
Thanks.
First, go to your root directory (the directory with yourproject.xcworkspace) and type "cat Podfile". This isn't completely necessary, but will show you the dependencies, just so you have an idea.
Then type "cd Pods". This will bring you to the directory where the dependencies are stored. Next, type "du -h". This lists the size of each directory, and will give you a pretty good idea which pods are the largest.
you can use this tool from Google https://github.com/google/cocoapods-size
It gives you how much byte a specific pod's binary add to your binary.
It basically uses an empty app and does the before/after comparaison
Exemple:
./measure_cocoapod_size.py --cocoapods AFNetworking
// Output:
Size comes out to be 231568 bytes (measured at version 3.2.1)
You can even pass custom sources, or use the diff yourself on your app ;)
When you build a project all your pods are built too. Usually(but not always) their location is the same as your final binary[Build location]. You will see how many space it takes on build machine
Also you can find it inside final consumer if you add dependency as dynamic[About]. You will see how many space it takes on device. In this case it will be smaller because doesn't include additional files
I was wondering here: Xcode: Clean and Build in a single step
how to Clean then Build your Xcode project in one single step.
I've still found no answer so perhaps there's a logical reason why you have to Clean then wait for that step to finish before doing a Build. It might only take a second or two but when you're repeating these steps over and over it seems bizarre they haven't been combined.
Any logical answers?
The clean and build operation are sequential. If you don't clean, old cached files will be used (saves time , if they are unchanged). IF you "clean", all files will be recompiled/re-processed/re-generated - costing a bit in time, but yielding a fresh start - sometimes the programs(Xcode) try to be too smart and get mixed up - too many old files left from previous builds. The clean sometimes solves that problem.
I have an iOS project with 5600 files in the source code repository. Xcode appears to visit all of those files during its indexing. Some of the files are large images that I can see no benefit to indexing. How can I tell Xcode to exclude those files so that indexing will go faster?
I'm aware of several other questions and answers that describe how to disable indexing entirely, but I didn't find any that address how to keep indexing enabled and tell Xcode how to skip irrelevant files.
One roundabout approach: Create one or more separate targets, and simply link to the object file(s) they produce.
justin's answer is good if you really need to create one or more separate targets. And I've searched but find you can enable/disable the indexing. I've not find anyway to exclude some kind of file when indexing. And you don't let Xcode index, you will lose some feature like autocomplete(Even for images, you can see the image name autocomplete in InterfaceBuilder).
If you are really sure you want to disable indexing. Use this in terminal:
defaults write com.apple.dt.XCode IDEIndexDisable 1
When you want indexing back:
defaults delete com.apple.dt.XCode IDEIndexEnable
defaults write com.apple.dt.XCode IDEIndexDisable 1
Another related article on How to make Xcode faster by solving Xcode slow issues with xcode 4.x