XCode 8.2.1. No problem with large single-target Mac project. Beaucoup problems with updating multi-target iOS project. Finally got it to compile and run after removing older (non-bitcode) Dropbox support (will add new back in later). However, the editor flags errors for some supposedly missing project files and reports 193 warnings, compared to 84 during a build/run. The files are in the project, in the same area as other files. We've tried "Clean Build Folder", removed and re-added files, etc. It's also fairly schizoid about what files it can't find. Some it reliably can't find, others more random. This is making it difficult to work off remaining warnings.
Preprocessor is Nuts
Here are some possibilities:
— Wrong target membership for files that "are in the project".
— Incomplete or inconsistent designation of frameworks header files as "private" or "public" vs. "project".
— Improperly updated include or frameworks header paths in the build settings.
— Improper file referencing styles for the frameworks (e.g. absolute where you need build-products-relative, etc)
— Inconsistent or unexpected use of modules (off/on) for frameworks.
— Incorrect or conflicting module names for frameworks (it got parameterized a couple of Xcodes ago).
— Errors/inconsistencies in schemes.
I'd suggest you try working through your targets individually, starting with the ones that have no other project framework dependencies, then moving on to the ones that depend on them. Check (or create) the scheme for each target, set it as the current scheme and make sure you can build each framework in turn.
Worst case, you can start looking at the compiler invocation lines for steps in the build transcript that reported missing files. You should be able to see path references to the files and from there figure out whether they refer to something that exists or not. (Sometimes can also see that the path is improperly quoted, so the invocation command line parameters are messed up.)
"Modules" was a good clue. The only place (I think) I used modules was in importing MultiPeerConnectivity. I changed that and turned off Modules in Build Settings.That seems to have cured a few issues, but not all. It still compiles and runs, in spite of the flagged errors.
Now, I'm mostly down to one import file in my AppDelegate that it can't find. However, that varies. Removing the flagged file and re-adding it to the project is ineffective in curing the error. However, moving the file to a different project subfolder and re-adding it(always clean folder)usually cures it for that file. But then it can't find the next file in the import list, and so on.
Running the preprocessor for the appDelegate file shows that it is importing what is needed. Closing the project and quitting XCode, relaunching and openin the project get me back to the not-respecting-macros problem in the appDelegate. Cleaning the build folder cures that, but gets me back to the above problem.
I don't know what you call the entity that looks for and flags errors and warnings in the editor, but this is definitely looking like some kind of an XCode bug. Judging from some of the messages I've googled, it looks like this bug may have been there for awhile.
It may be that there's a bug with the errors for a given target not being deleted even though the target is rebuilt. If that's the case, I'd suggest:
1. Rename the target, and see if the errors go away properly. Assuming not …
2. Duplicate the renamed target, and see if the errors are still there. Assuming they're gone …
3. Rename the duplicate to the original name, and see if the errors come back.
If it's a problem with the compiler finding header files (or, more precisely, Source Kit finding a different set of header files during editing than the clang compiler does at build time), then you might be in some kind of C include ****. This is beyond me, because I don't know the official rules about what assumptions C compiler are allowed to make about filenames and paths, and I think Xcode has strategies for compiling faster by remembering lists of header files. Also, Xcode keeps source files open that you are no longer editing, and I suspect what files are open have significance to the search order, in cases of ambiguity, which means the outcome of any particular build may depend on what files you ever looked at since launching Xcode.
However, it might be worth checking:
— that #import and #include statement are all using the correct kind of quotes ("..." or <...>)
— that you aren't using #include anywhere that should be #import, or vice versa
— that you don't have files that are literally being included more than once, or duplicate but different files with the same name but different paths, or something like that
Also, it's possible that there's something odd going on with a precompiled header. Xcode caches precompiled headers in a different place from the regular build folder, so a clean doesn't necessarily delete them. You might try deleting the entire DerivedData folder, rather than just the project-specific sub-folder.
Finally, if it's going to be an ongoing problem, it may be worth taking the time to recreate the project from scratch.
A search shows the only "#included"s are in a TCPServer class I got from some Apple sample code, used in the iPhone remote control target. None in the three iPad targets with which I am currently working.
This is a fairly complex project. Basic version, Standard version, and Advanced version. If I were going to recreate the project from scratch, I would want to reorganize my project subfolders which are currently a mess. Getting files included into the right targets would also be a feat. Not looking forward to that. This was originally supposed to be a routine maintenance update.
I'll try the rename. Seems like it needs a reset of some kind.