Having updated Swift + ObjC project to Xcode 8 (Swift 2.3) I found 50% or more of the time Xcode does a full rebuild of the project instead of an incremental build.
The changes made are adding simple print statements. There seems to be no logic as to when it performs a full rebuild.
It appears in the "Check dependencies" phase it decides this. On Xcode 7 this did not seem to be a problem.
Has anyone else encountered this?
I have found this works consistently, it will however compile swift files if you modify a header included in the bridging header. It will also do full compile if you switch git branches back and forth.
Firstly make sure optimization level for debug is set to None (Not whole module optimization)
Then, according to https://forums.developer.apple.com/thread/62737 Apple Staff (ddunbar):
We believe that setting:
HEADERMAP_USES_VFS = YES
to true in your project (or for all your targets) may be an effective workaround > for many people. This is not guaranteed to work (which is the reason it isn't > already on by default), but it should work for most projects.
This should be added through "Add user-defined setting" under your target Build Settings.
.
Ok, here's an answer to why it's happening, but I don't know the solution. If you use the "Other Swift Flag" -driver-show-incremental Xcode will output what it decides it needs to compile based upon it's dependancies. You'll see things like:
Queuing EditProfileViewController.swift because of dependencies discovered later
Queuing ChangePasswordViewController.swift because of dependencies discovered later
Queuing JoinViewController.swift because of dependencies discovered later
Queuing JoinProfileViewController.swift because of dependencies discovered later
Queuing FormViewBuildable.swift because of dependencies discovered later
Queuing RadioTextFormView.swift because of dependencies discovered later
Queuing TextFieldFormView.swift because of dependencies discovered later
Queuing AccountProfileViewController.swift because of dependencies discovered later
I'm wondering if this is a swift 3 problem, because I wasn't having this issue before converting. I made a little example project where
FileA inclues a thing from FileB includes a thing from FileC
and even adding a file private change to FileC that's not used anywhere causes FileA, FileB, and FileC to be queued for compilation due to dependencies. I'm going to be testing this example in Xcode 7 later today to see what happens.
So it looks like swift 3's dependency resolution isn't working very well. I've tested this on 2 other swift 3 projects at work, and the same holds true. Make any change in any file, and every file gets compiled. It doesn't feel slow until you start getting to projects with about 15,000 lines of code or so, which may be why nobody is talking much about this. Unless you have a somewhat medium sized swift 3 app, you probably won't even notice that incremental complication isn't working quite right. I'll update if I learn anything more.
Apple released new beta version of Xcode yesterday (Nov 14)
Xcode 8.2 beta 2
And this issue has been marked as resolved in the release note.
Build System
• Xcode will not rebuild an entire target when only small
changes have occurred. (28892475)
It is working for me. The build speed came back as usual.
Everybody who is facing this issue, should give it a try!
https://developer.apple.com/download/
Unchecking "Find Implicit Dependencies" in Edit Scheme > "Scheme" > Build tab fixed it for me for project files. "Copy swift standard libraries" still takes forever..
Related
Just to get some context here is a screenshot, though you probably gathered this from the title:
Xcode is marking all symbols as undeclared, usually this would be because it doesn't exist or isn't imported, but in this case it was working fine 20 minutes ago and weirdly the project compiles and runs with no problems.
When I compile the errors go away but there is no syntax highlighting, as soon as I start to edit the file the errors all come back. I can work if I remember the exact signatures for anything that I need to use but with the lack of code completion and errors this is very hard.
Notably this is only a problem in a few source files, its not even the whole project. Nothing has changed that I am aware of that could cause this.
Before anyone suggests it, I have tried cleaning, deleting derived data/build folder, restarting Xcode etc...
My colleague is seeing the exact same issue on his machine.
So I managed to fix the offending source files, I just compared their attributes to those of a working source file and it turns out that the problem files included the tests project in their target membership and the working file did not. I'm not sure why this is causing the issue as other projects use automated testing without a problem. Nonetheless this solved it for me, at least until I start writing test cases...
Is there a way to output the time taken to compile a swift file during an xcode build?
I would like to compile from the command line to trigger the same build xcode does but to include the time taken to compile each file.
The Report Navigator show full build reports per file but there is no timeframe associated with them.
I would like to cut down the compile time of a Swift 1.2 project, as it takes around 5 - 10 minutes after a clean or 3 -5 minutes after changing source in a heavily dependent file.
You can add…
-Xfrontend -debug-time-function-bodies
…to Other Swift Flags in Swift Compiler - Custom Flags section (build settings).
Note: You have to keep same order of these flags. -Xfrontend says that the next flag should be passed to the frontend. It will not work if you reverse the order.
Then you can get compile times in your build log:
Which is useful when you do want to optimize compile time and also it's good to attach this kind of build log when reporting an issue to Apple Swift guys about slow compile time.
Credit goes to Joe Pamer Errant compiler hacker. Currently an engineering manager at Apple (Swift, Clang), formerly at Microsoft (TypeScript, F#, JavaScript, .NET). He tweeted it as a response to Rob Rix question about profiling Swift compilation. It made me curious, so, I disassembled compiler, checked text section for more flags and found other hidden options. Don't use them in production code, just play with them.
Build time of the whole project. Run following command in terminal…
defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
…restart Xcode, clean & build and…
What if I have pods?
Do same as above for your pods project
This problem has been KILLING me. I've been working on this app for 8 Months, and I am so close to finishing, I just can't seem to build for device. Building for the simulator works fine, but device always gives me the SAME 2 errors.
The 1st Error:
"Instruction requires a CPU feature not currently enabled"
From googling, I've found this probably means I'm not linking a binary I should be, but I'm not sure.
The 2nd Error:
If you can't read it, it says: Generating JWFNS.app.dSYM ... error: unable to open executable '/Users/ajr1188/Library/Developer/Xcode/DerivedData/JWFNS-azshgysfabycfagnebotitpcyaww/Build/Products/Debug-iphoneos/JWFNS.app/JWFNS'
This is the big one. I cannot seem to build the .app.dSYM file properly. I went in and deleted the build folder, I looked at EVERY stackoverflow question I could find and tried changing any random thing mentioned in another question, but all of it is to no avail. I'm so suck right now. AHH. PLEASE. Any help would be so appreciated!
Maybe your project has become hopelessly corrupted. One thing to try is to start a brand new project and copy/import all your sources/assets into the new project to see if that fixes the problem.
Another less nuclear (but perhaps more time consuming) approach is to binary search the build. Exclude absolutely everything except main.m and see if that fixes the problem. If it does, include half your sources, and buid again....repeat, trying to narrow in on the problem spot. Maybe a file or group of files has received special build settings that don't belong there.
I've had very similar problems, I cant remember the exact error message but it was very similar. Are you able to make a new project that will run on your device?
if so (and I know this sounds bad but it's worth a try) Create a new project and simply copy all the code and resources across and see if it still works. If it doesn't then there is something wrong with you code and you can continue trying to isolate the problem from there.
Hope this is helpful.
check the frameworks you link to. there's a chance that you linked a framework (say quartz) of osx, instead of ios.
Answering in detail is probably going to take looking at your target settings. But it looks like you may be building for the wrong architecture. (It doesn't link, so there is no .dSYM symbol file.) For example, if you have only recently built for device, you probably created your project under an older Xcode, and it may not have the arm6/arm7 settings right.
To check, show the Build Settings for your target (not the project), and filter on Architecture.
Make sure that in build settings the architectures are armv6 and armv7. Also make sure that in .plist file, the "Application requires iPhone environment" is TRUE. Delete "Required device capabilities" in the .plist if present.
This is similar to another question that wasn't really answered: Xcode 3.2: Build & Analyze never finds any issues
I used XCode's Build and Analyze for the first time on a large project and came up with a number of analyzer warnings. I corrected a few and wanted to verify my changes were being 'accepted' by the analyzer. I didn't even look at warnings in a number of files. But when I re-run Build and Analyze, all the warnings are gone.
I have tried: changing my compiler to LVVC GCC 4.2, switching from a debug to a release build, cleaning all (repeatedly), and quitting and reopening XCode. I just can't get the old warnings back.
Build and analyze only analyzes your modified files.
Go to your project settings -> build tab. And check 'Run Static Analyzer'. This runs a full check on all files on each build.
It is how XCode built with. Whenever, you build the project (even using build & analyze), it will build only those files which are modified before the last build. So if you want to have your old warning & analysis result back, do clean all targets from build menu & again build.
I had a similar issue some days ago. I had plenty of warnings, and after some changes in the code the analyzer warnings disappeared. Even a clean build could not bring them back.
By a coincidence I changed the message filter in the build log from Issues Only to All messages.
And there were plenty of messages related to the disappear of analyzer results. The analyzer complained that he could not analyze my files. I'm sorry I don't remember the correct message.
As far as I remember I put some code into the .pch which confused the analyzer completely. After I changed a lot of stuff analyzer was happy again. Magically. I still don't know why that happened and I can't reproduce it.
For whatever reason, none of the solutions above worked for me. The only way I could get the warnings back was to open the project with XCode 4 and analyze it there. I am taking screenshots so I don't lose these warnings. I hope the analyzer works better in XCode 4 in the future.
I think the title is pretty clear. I have ran into this twice now.
The first time it indicated a problem, and my project wouldn't compile.
The second time everything still worked.
Is it just a fluke if my code still builds when this turns red?
Anything in the files and groups list that turns red indicates a missing file or directory. This is not necessarily cause for concern, because in many instances the file is expected to be built as part of your build process.
In the case of your linked static library, you are probably depending on a second target or project to build the static library. When you changed build configurations, Xcode noticed that it had not yet been built, so it shows it as red. When you built the project and the dependent library was itself built, it turned black again.
The first time it indicated a problem, and my project wouldn't compile. The second time everything still worked.
That suggests that you don't have your build dependencies set up correctly, which will bite you every time you do a clean build. You need to make the target(s) that need the static library have an explicit build dependency on the target that builds that library.