What is the actual difference between both these actions?
I ask because I find cleaning (Cmd-Shift-K) a slow, time taking process, and deleting the whole DerivedData folder much more faster.
More Info
1) I have set my DerivedData folder to be in a relative folder to my project folder in the XCode preferences.
2) I usually deal with projects with only one target. Very rarely I have to deal with 2 or more targets.
This is explained in Use Your Loaf's article on Xcode 4 DerivedData and Cleaning the Build Directory.
In Xcode 4 the Product > Clean menu option cleans up the build directory for all targets by deleting the app and dSYM files along with the precompiled headers.
DerivedData on the other hand contains other stuff:
Each workspace gets a unique set of symbol indexes, build products, window layouts, etc., otherwise referred to by Xcode as derived data.
So, the answer if you want to really clean everything, is to use the new Xcode 4 Clean Build Folder action by selecting the Product menu whilst holding the Option key. That will also delete the DerivedData contents:
Clean is slower, because it deletes file by file, not whole folder
After deleting DerivedData folder you'll get some slowdown, because XCode has to recreate indexes for your sources.
There is 'Clean Build Folder...' command (Option-Cmd-Shift-K, or select Product menu and press Option button). It removes folders not files, so it can be faster for you.
Related
DerivedData keeps returning into my project no matter how many different ways I try to delete it. This is causing a compile error.
I believe it is related to my deletion of my Core Data model class and extension (I realized I needed to add an additional property and this seemed easier than migrating since I hadn't actually implemented it yet). I deleted the files and removed the reference to these files, but that seems to have not worked. This is the error I've received:
I have tried:
-Cleaning
-Cleaning Build Folder
-Resetting Simulator Content and Settings
-Removing the DerivedData folder using "git rm -rf --cached ."
-Deleting DerivedData folder using Finder, Xcode and Terminal
-Deleting the Module Cache
-Deleting Xcode preferences (defaults delete com.apple.dt.Xcode)
-All of the above combined with quitting Xcode and/or restarting my computer
-Following all suggestions in the following threads on SO:
Xcode 6 Swift code completion not working
How can I delete derived data in Xcode 8?
Xcode keeps remaking derived data folder after I delete it
https://forums.developer.apple.com/thread/81265
https://iosdevcenters.blogspot.com/2015/12/how-to-delete-derived-data-and-clean.html
For the sheer hilariousness of it all, I have my project folder open in Finder when I try to run the project and can see the DerivedData folder being created as soon as I press the play button. Good times.
This is a view of my build/compile settings in Xcode to show that I don't have those files listed twice:
How can I fix this?
The error suggests that you have Core Data code generation turned on and also have a copy of the generated code (or at least a file with the same name) in your source code repository. That's why it complains of a duplicate. One is located in your Model folder, and the generated copy is located in derived data.
You can resolve this by either
Changing the setting in your data model so that Core Data doesn't generate code for this entity anymore, or
Deleting your copy and letting Core Data do its thing.
Either is valid and should work. Or, if the files are actually different in some meaningful way, rename yours so that the name doesn't conflict.
On a related note, the derived data folder always comes back because that's where Xcode puts all of the stuff it generates while compiling your project. It's not just generated source code, it's also things like compiled object code files and eventually the app itself. It comes back because that's how Xcode compiles the project.
You can't prevent Xcode from generating derived data for your project. No matter how many times you delete the folder, it will always regenerate.
I've come across similar issues in the past where the compile time error points to derived data, but something else is causing the issue.
From the looks of it, some of your files are being included twice in your project, and your getting name collisions. Check that you don't have duplicates in you build settings for bundled/compiled resources.
Difference xcode to perform clean and remove the DerivedData?
The more detailed the better.
Clean menu cleans up the directory for all targets by deleting the app and dSYM files with the precompiled headers.
Derived data contains symbol indexes, build products, window layouts of respective app. After deleting DerivedData Xcode has to recreate indexes for your sources, so it becomes slower at times.
Refer this link for detailed explanation : http://useyourloaf.com/blog/xcode-4-deriveddata-and-cleaning-the-build-directory/
I need to figure out why it is that Xcode, suddenly and with no provocation, starts handing me this error and not allowing me to build my project. When I say, "without provocation", I mean I'm editing text in the database the app delivers text from, and checking my progress in the simulator, doing nothing in Xcode at all except cleaning, building and testing. Everything will be fine for several test sequences, then suddenly, changing nothing in my procedures, the app won't build and I get these errors:
error: remove
/Users/casey-cayce/Library/Developer/Xcode/DerivedData/PEM-LTE-2016-gyoajgqmkkoluhgbrhjmgwakiejl/Build/Products/Debug-iphonesimulator/Living
the Eucharist.app/images: Directory not empty
error: couldn't remove
'/Users/casey-cayce/Library/Developer/Xcode/DerivedData/PEM-LTE-2016-gyoajgqmkkoluhgbrhjmgwakiejl/Build/Products/Debug-iphonesimulator/Living
the Eucharist.app/images' after command failed: Directory not empty
I've gone to this Derived Data folder and physically deleted the contents, only to have Xcode restore those contents when I reopen the app, fail the build, then give me the same errors over again. My only solution so far is to completely delete Xcode and the Developer folder, reinstall Xcode, after which it behaves fora little while, but will eventually do the same thing again. I've done this 3 times so far today.
If anyone has any suggestions, please help me get this resolved so I can get this project exported and finished.
Thanks.
Additional info in response to responses:
I have:
1: Closed the project.
2: Opened the Projects, folder and deleted the Derived Data, seen the Projects folder go blank (empty) with "No Projects" showing in the window.
3: Made sure the trash is emptied.
4: Run "WatchDog," an app developed specifically for dealing with Derived Data issues in XCode.
5: Closed Xcode & re-opened.
6: Opened the project, cleaned, and run the Build command.
After all that, the same errors come up again.
Check your "Copy Bundle Resources" in Build Phase, You should find some files(should be images in your situation) in that list twice. Delete them and rebuild.
It is ok to delete DerivedData folder, you can delete all files from DerivedData sub-folder (Not DerivedData Folder) directly.
That should not take any effect. Contents of DerivedData folder is generated during the build time and you can delete them if you want. It's not a issue.
All contents of DerivedData will be recreated when you build your projects again.
I suggest you clean project project and build again, ALSO PLEAE MAKE SURE YOUR DELETED DerivedData folder is not in BIN please clean trash, it is important
In Xcode go to Window > Projects, select your project and there will be the delete button to delete the derived data.
As of Xcode 9/10 you'll be able to access the Derived Data folder by navigating to
File -> Project Settings
or if you use a Workspace:
File -> Workspace Settings
And press the arrow behind the path:
Go to the folder and delete the derived data
Add this to your shell and it will remove the DerivedData
rm -rf ~/Library/Developer/Xcode/DerivedData/*
It's not the best option, but helps me a lot of times - create new project and drag all source files from current in to new one.
I tried to remove test target from Xcode project so I followed suggestions from this Stackoverflow post.
Then I deleted AppnameTests folder with files in it (AppnameTest.m and info.plist) by right-clicking and choosing move to trash. Also tried Xcode->Edit->Delete for deletion.
After that, I tried to clean project, but one weird thing is happening. Folder AppnameTests is not removed after deleting that folder trough Xcode (files inside it are gone). It can be removed only manually using Finder, but I don't think this is a good idea, because maybe Xcode keeps reference to this folder.
I am using Xcode 6.1. Anybody experienced this? Why is this happening?
EDIT:
Here is what I see in finder after deleting (yellow) folder called AppnameTest using Xcode's delete command:
The folder itself from filesystem is not removed.
In Xcode, if the folder 'AppnameTests' is yellow, it is not a folder, it is a group. If it is blue, it is a real reference to a real folder.
In general, just after creating a new project in Xcode, this folder is yellow, and s it is not a folder, but a group that is a link to a folder (group has not necessary a corresponding folder in the Finder).
You can remove this folder by hand in Xcode (I do it regularly).
I have a workspace, Application.xcworkspace, that builds two frameworks and an executable that uses those frameworks. Here is roughly how they are laid out:
Framework_1 - Built and output to ugly DerivedData path.
Framework_2 - Depends on Framework_1, which is included in the Frameworks area of the project and specified in the "Link Binary with Libraries" Build Phase, and output to ugly DerivedData path.
Application - Depends on Framework_1 and Framework_2, which are included in the Frameworks area of the project and specified in the "Link Binary with Libraries" Build Phase. Output directory is again that ugly DerivedData path.
The problem I have is that the paths in the project file for the referenced frameworks are the DerivedData ugly path - they are like ../../Library/Developer/XCode/DerivedData/Application-longuglyuniquestring/Build/Products/Release/Framework_1.framework.
If I copy the source to another directory, or check it into version control and check it out to another machine, then those framework paths are no longer valid. They get re-generated. The referenced frameworks show up as red in the project.
So far, when I want to build the workspace in another folder, the way I have fixed the problem is to:
Build the workspace - Framework_1 builds.
Go to the "Products" node for that framework and show it in Finder.
Copy the new ugly path.
Open the project files for Framework_2 and Application and correct the path for Framework_1 and Framework_2.
All the red items should be resolved and everything should build.
That process is tedious and I am lucky the project file can be edited. It is worse for colleagues that do not understand the little I know about the project files, and just want to check the code out and have it build.
Is there something I need to do to the Build Output Directory for the frameworks? I have been leery of changing it since the ugly path is recommended. Is there a copy files option I can use to put those frameworks in some predictable location relative to my workspace?
Any help would be appreciated. I am sure I am missing something simple - it makes no sense that code checked out of source control or copied to another directory would not just build.
Looks like there is a way to set the DerivedData directory on a per-workspace basis - Xcode 4 - build output directory
I just set DerivedData to be relative to my workspace, then edited the project files accordingly. The only down-side is if I were to use one of those projects in another workspace that was using the default DerivedData path, I would have to change them back.
Many thanks to user DaGaMs - he got an upvote.
I am still seeing bad behavior from XCode 5: I got the project working on my machine. Copied it to another, lower, directory and verified it still worked. Exited XCode and copied the containing directory to a network drive, and from there onto another Mac. When I opened it on the other Mac it was like I never made some of the changes. Even worse, as I worked to fix it, XCode went nuts and added 6 extra '\' characters to each end of my FRAMEWORK_SEARCH_PATHS paths!
Part of the problem stems from the subproject directories in my app being absolute rather than relative. The projects in the top of the workspace are "Relative to Group", so I changed the subprojects to have the same attribute. That seems to have solved the problem, though for some reason when I copy all the files to another machine, the Derived Data redirection does not go with it.