I have an Xcode project (objective c, Xcode 8.2.1).
Whenever I do "Clean build" and build again, it takes a very long time. I started to look into the reason for this and I noticed that all my pod source files are being compiled twice (which I guess doubles the compile time).
At the top of Xcode, you can see the status of the build as it progresses
You can see in the screenshot above that Xcode is compiling 142 source files for the Realm pod, but it only has 71 source files. All my other pods have the same issue.
I tested creating a new xcode project and adding pods, and then I don't experience the same problem as in this project.
#Bdash suggested that I might be having the build setting "Build Active Architecture Only" set to "No", but I have checked this and it is set to "Yes".
Any ideas on what could be the problem here?
This tends to happen when you have custom names for your build configurations. That is, if you have a name other than Debug or Release, CocoaPods will treat such configurations as release ones. Besides other things, this means enabling optimizations and setting the Build Active Architecture Only flag for those Pods to YES. Both options will hinder compilation times for Debug configurations.
To fix it you have to specify which configurations are Debug ones. Following the docs, you have to change your Podfile so it looks something like this:
project 'MyApp', 'MyAppRelease' => :release, 'MyAppDebug' => :debug
Unfortunately, Realm is a large project with a significant number of C++ and Objective-C++ source files, and generally takes a while to compile (especially after cleaning the build folder). Exactly how long Realm takes to build depends on what sort of computer Xcode is running on, but the numbers you provided don't seem to be unreasonable for older hardware.
Related
After updating Xcode 10 from AppStore, when i add something even one single line, it doesn't apply change to build while i clean project. Is there any trick to prevent this or is it bug.
edit: i'm developing cocoapod, changes in Example app is applied to compile perfect but changes in development pod is require to clean to apply changes.
This is a known issue with the new build system of Xcode 10.
There are radars about this and cocoapods developers are aware of the issue.
In the meantime (because it is not gonna be fixed anytime soon), you can indeed switch to the legacy build system (or clean your build folder each time you want to recompile your example app).
Another option might be to disable cocoapods input/output paths, but it is not recommended.
Please note that switching the Compilation Mode build setting from Incremental to Whole Module will in fact not work as intended.
For more information about this you can check the following issues :
https://github.com/CocoaPods/CocoaPods/issues/7966
https://github.com/CocoaPods/CocoaPods/issues/8073
I have a library project that used to build just fine in Xcode 7.2. If I just compiled it, it would rebuild it on subsequent builds. After upgrading to Xcode 7.3, Xcode recompiles all the files on every build even if I make no changes to any file.
I did a deep clean and also deleted the derived data folder to make sure that was not the cause. The dependent library projects build fine (they don't recompile everything) when I compile them independently. I have looked through all the settings but couldn't figure out why this is happening.
I stumbled upon 2 things that "fixed" the problem but I don't want to use any of these "solutions"
I changed the Optimization Level (for LLVM) from None [-O0] to Fastest, Smallest [-Os] and that did the trick. Im not sure why without the optimization it recompiled all the files, all the time (even if it was not changed).
I have a pre-processor flag (DEBUG=1) for debug builds and if I remove that flag then it stops recompiling all the files, all the time
The above 2 options don't work for me.
Has anyone seen similar behavior?
I figured out the problem. In Xcode one of the Build Settings was not set correctly.
The "C Language Dialect" was set to "GNU99" instead of "Compiler Default". Previously the standard was GNU99 but now its not. At some point Xcode did not migrate the library project settings correctly and so it was set to GNU99. Once I changed it to GNU99 it stopped recompiling all my code every time !
I recently update Xcode to Version 7.1, which included Swift 2.1. I installed Swift 2.1 with no troubles. After attempting to run my project, I realized that I needed to grab the latest version of Realm, since the previous version did not support Swift 2.1. I deleted the old frameworks and imported Realm 0.96.2. Whenever I run, I now get this error:
bash: /Users/userName/Library/Developer/Xcode/DerivedData/appName-ghiroqitgsbvfhdqxsscyokyoouz/Build/Products/Debug-iphoneos/appName.app/Frameworks/Realm.framework/strip-frameworks.sh: No such file or directory
I suspected the problem was with the script that is required if you wish to submit your app the the App Store, so I removed the Run Script Phase, added a new one, and copied the script from the Realm documentation site:
bash "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/Realm.framework/strip-frameworks.sh"
I thought that that would fix it, but it did not. I then thought that the problem may be in the Realm.framework or RealmSwift.framework files, so I removed them and re-imported them (Just in case I messed something up). Nothing changed. Does anyone know if there is a fix to this error?
Thanks!
-CodeIt
From the error message, it seems like, you didn't added Realm.framework and RealmSwift.framework to the Embedded Binaries pane, which you find in the General tab of your project, as shown below:
For further validation, you can check the tab Build Phases. It should look like below:
Note: Make sure that the run script phase comes after the Embed Frameworks phase.
Why is this script needed?
The vendored frameworks are not just single executables, but actually FAT binaries which are archives of linked executables on different architectures. This includes architecture slices for arm64 and armv7, which are necessary for deployment on the phone as well as i386 and x86_64 which are necessary for running the app in the simulator.
The strip-frameworks.sh script main responsibility is to take care of removing unnecessary slices. This reduces the final package size and is necessary for AppStore deployment because iTunes Connect rejects apps with simulator architectures.
More Details
The script works on base of the build setting VALID_ARCHS. Because that is changing the signed executable of the framework, it also needs to take care of code signing. Since introduction of bitcode, it also got further post processing as responsibility. It extracts the included *.bcsymbolmap files from the framework bundle and places them into correct path in the *.xcarchive.
The FAQ topic on Bitcode of PSPDFKit has a good explanation on what BCSymbolMaps are:
A BCSymbolMap is a lot like a dSYM for bitcode. Xcode builds it as part of creating the app binary, and also for every dynamic framework. It's required for re-symbolicating function/method names to understand crashers.
In my case, change the process order in Build Phases to solve
not OK
OK
I have returned to a fairly large project that uses RestKit and many other libraries.
The existing target builds and archives fine. Xcode 6.4, SDK iOS 8.4, target iOS 7.0.
I did this:
Duplicated the existing target.
Added some pre-processor macros and a different product name
Expected the new target to build and archive successfully.
Now the build fails with:
(null): Library not found for -lPods-AFNetworking
NOTES:
I have compared the raw target details and they are identical apart from the few changes I noted above.
I don't really want to run pod install on the project. Why? Because I'm afraid, yes. And because I don't want to spend much time - I just need to make a variant build and then move on to something else. A pod install after a period away could cause unwanted breakage.
I have had this problem before on the very same project, and yes I am cursing the former me for not making better notes at the time, but the former me says that he was fatigued and pissed off with it at the time and couldn't bear another minute, and knew it would come back to bite the later me in the arse.
So now before I bang my head against this again, I am hoping a kind and generous soul reading this will share a golden path of light that leads up and away from the pain directly to the promised land of a clean build.
I'm using Xcode 4.3.3. My project has 2 targets and they are very similar (one was a duplicate of the other). The only thing is they have different names and there is a small amount of #ifdef going on. One project compiles a few more files and copies a few more bundle resources than the other. Other than that they ought to be the same. It's like having Pro and Lite app versions.
I seem to have a few issues (building for one of the targets is absolutely fine, so all these issues relate to the 'other' target)...
When building the 'other' target it gives me the warning "Multiple build commands for output file...". It is referring to 'icon-72.png'. However, I've not only removed the second reference to that file (still got the warning), but I have also removed that file entirely and removed all references I could find for it, including deleting the icon from the Target Summary, ensuring the file doesn't exist in any project folder in Finder for this project, and also ensuring it's not listed in 'Copy Bundle Resources' in 'Build Phases'. The warning still appears.
When building the 'other' target it doesn't give me the usual warnings. These warnings should exist in both builds at this time. I have checked what is being compiled and the files that should generate these warnings are included in both 'Compile Sources' in both targets' 'Build Phases'.
Building the 'other' target gives me 'Failed'. However, in the Issue Navigator there is no explanation as to why it failed.
Incidentally, the 'other' target was the original one, not the new one.
Also, I have tried cleaning before each build attempt and have also restarted Xcode. I have recently restarted the computer too.
Any help or general pointing in the right direction would be greatly appreciated.
Atb.
EDIT....
I updated the project settings as prompted in the Issue Navigator to use LLDB. Now I don't get any warnings for either target, but the 'other' target still fails to build without reason.
Right. Well, it turns out that this was mostly the answer (check the last comment). I closed the actual Xcode window with my project in (cmd-W), then I went to File > Open and opened the project file from there (as opposed to opening it from the splash window or the recents list).
Now I can see the warnings and tell why the build is failing too. Phew!!