Project Won't Build with .h File

This morning my xCode project stopped building. I'm using XCode 14.2 and Mac OS 12.6.6. A .h file has been in the project for years and the project has been built hundreds of times with this file. Today XCode stopped building the project with two errors;

The .h C header file has only this:

#include <stdio.h>

void func(char *foo, char *bar);

XCode reports an error: Expected identifier or '(' with the underscore unuder the void return type. Obviously this is a spurious error.

Also the analyzer reports: header 'headerfilename.h' is not a member of any targets in the current scheme that build for running. XCode shows that this is in the project in the Identity and Type pane. The project shows this in the pane but with header files the check box is not checked - only .c and .m files, so this is apparently a spurious error as well.

This is weird because I didn't do anything to change this. Also there are a lot of other .h files in the project that are used.

In, order to fix this I have cleared the build folder and rebuilt the project. removed the .h file from the project and built the project, then added it and built it with the .h file in the project. In Identity and Type info pane the .h file shows Target Membership in the project. I removed the whole group with the file and added it again being sure to check the box for target membership but it still won't build this .h file. Other files are added to the group but not this one.

I have experienced a lesser version of this before with .h files but after building the project a couple of times XCode fixed itself. Not this time. XCode got up this morning on the wrong side of the bed and it decided it won't build with this header and I can't add it to the project.

Any suggestions?

Answered by Tlaloc in 759037022

Problem solved:

When XCode crashed I wound up with a single '*' way down in one of my header files. When I looked at it I wouldn't see it. This is weird because I wasn't doing anything with that file. I probably did it myself but I don't know how. Then the preprocessor would add the header file to the source code file and when it built it would report an error but not in a way that told me what was wrong. Another strange thing is that it reported this error in all of my .c and .m files so when I followed johnSOS' very excellent advice to preprocesses some files and look at the output, I didn't happen to look at ones with the messed up header file. So, XCode was very unhelpful in letting me find the problem.

Also strange, DTS can't build my sample project without #import <Cocoa/Cocoa.h> in one of my .h files so the .m file knows about Cocoa. This looks like a bug because the project includes an appname_Prefix.pch file with:

#ifdef OBJC #import <Cocoa/Cocoa.h> #endif

This is supposed to be a prefix file for all source files in the target so they know about Cocoa. This is weird.

Finally one of my source files wouldn't compile for DTS without <Foundation/Foundation.h> in its header. This is also strange because it did for years for me. Maybe I should #import this in the .pch file as well just to be safe.

Finally DTS suggests that I use DIF to file errors. I've never had to do this before but I will.

Thanks to everyone for helping me with this issue.

Accepted Answer

Problem solved:

When XCode crashed I wound up with a single '*' way down in one of my header files. When I looked at it I wouldn't see it. This is weird because I wasn't doing anything with that file. I probably did it myself but I don't know how. Then the preprocessor would add the header file to the source code file and when it built it would report an error but not in a way that told me what was wrong. Another strange thing is that it reported this error in all of my .c and .m files so when I followed johnSOS' very excellent advice to preprocesses some files and look at the output, I didn't happen to look at ones with the messed up header file. So, XCode was very unhelpful in letting me find the problem.

Also strange, DTS can't build my sample project without #import <Cocoa/Cocoa.h> in one of my .h files so the .m file knows about Cocoa. This looks like a bug because the project includes an appname_Prefix.pch file with:

#ifdef OBJC #import <Cocoa/Cocoa.h> #endif

This is supposed to be a prefix file for all source files in the target so they know about Cocoa. This is weird.

Finally one of my source files wouldn't compile for DTS without <Foundation/Foundation.h> in its header. This is also strange because it did for years for me. Maybe I should #import this in the .pch file as well just to be safe.

Finally DTS suggests that I use DIF to file errors. I've never had to do this before but I will.

Thanks to everyone for helping me with this issue.

When my program starts up it calls some code to validate its App Store receipt. Now this logs the same error three times:

2023-07-14 11:35:23.905145-0600 appname[2702:35564] [Security]

delegate_identifier:Performance Diagnostics__:::__message:This method should not be called on the main thread as it may lead to UI unresponsiveness.

Yes, I can guess what it wants me to do but this is an example of an unhelpful message.

Also one has to wonder why this would affect other projects as well as the one with the error in a header file...

Does anybody think that Swift is tiny bit out of control? Too large? I do. Optionals, Protocols, Properties, Methods, Classes, Generics, Extensions, multitudes of parameter invocation methodologies, Macros which code at the level of the AST, Opaque or Boxed types, Repl's, Playgrounds, (compiler/interpreter), Closures, Automatic Reference Counting and last but not least "Advanced Operators"... Could be a problem in that open source community designs the language and then Apple has to produce a professional product in real time. Whew, difficult.

I feel for you Taloc. As an old-time command line programmer, the good ol -E flag would have the pre-proccessor spilling it's guts, and it helped me with a difficult bug lo those many years ago.

Project Won't Build with .h File
 
 
Q