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.

Today I upgraded to MAC OS 12.6.7. After I restarted my mac XCode asked me to install additional shared components. I did. This didn't help.

According to XCode Help You can go to File > Project Settings... This will show a panel that will have a pop-up menu to select either the old or new Build System. This sounded promising but unfortunately In XCode 14.2 there isn't really any pop-up menu to do this. No help from DTS.

I moved everything to a new 24" Apple silicon iMac, hoping that it would help. I installed XCode 14.3.1. During the installation from the App Store it checked my old version of XCode and it said that it was damaged and recommended that I move it to the trash - good idea, since it was FUBAR. After I installed XCode 14.3.1 I tried to build my most important project it still won't build, With the same errors - it can't build any .m or .c file with a #include or #import any .h. Any .h header file in the project won't build with a spurious error: Expected identifier or '(' at the first line of text after the #includes. Then the file in which the .h is #included won't build:undeclared function (in the .h file that won't build).

The newer version of XCode reports a different error: missing input '/Users/myname/Library/Developer/XCode/DerivedData/appname-gobldegookishkabibble/Build/intermediates.noindex/appname.build/Debug/appname.build/Objects-normal/arm64/sourcecodefilename.o'and no rule to build it

Of course this is not helpful. I filed a DTS request for help on June 16th - 19 days ago but all I have received is a response saying that DTS is swamped (I'll bet) and that when the representative assigned to this case has some time I will get a response. I'm guessing that this will be never.

I guess that when XCode decided to commit suicide it also killed all of my projects. On difference is that I don't see an XCBBuildService crash in the Console.

Now there is a little good news. This computer has a number of small projects used to develop relatively small pieces of code for use in larger programs. These will now build and run. I don't know if I can add new .h, .c or .m files to them but at least they build and run.

Since there is some problem with files in the files/folders created for my program that I need to update, could I delete everything related to the project in my ~/Library/Developer/XCode/DerivedData/appname-ishkabbiblegobbldegook folder? Or at least the ishkabibble/Build folder? When you create and build a new project, XCode creates these so will it create the folders/files it needs or will I be even more screwed than I am now?

I deleted the derived data of some small projects to see if XCode will re-create it and run. Yes it will. Doing it on my main project it will re-create the derived data but my project still won't build. It still reports the spurious errors.

I decided to create a new project. This was very difficult because XCode wanted me to a lot of things that weren't required before and aren't described as needed in the documentation, for example put the project in a workspace and use a hierarchy with the .xcodeproj in a folder with the source code files in a folder in the same parent folder. I still have the same problem. I can drag a .h file from the source code files to the project navigator. XCode asks if I want to add it to the target. I check yes but when I build the project I get two errors: in the .h file the first character in the first line of code is underscored and there is an error "Expected identifier or'('. The second error is if I analyze or compile the .h file: "'headerfile.h' is not a member of any targets in the current scheme that build for running". When I use the attributes inspector to look at the target membership of the .h file the checkbox for target membership is not selected.

Obviously these are spurious errors. I can't build any .c or .m file with the header #included or #imported because XCode won't add it to the target.

It has now been three weeks since I filed a Developer Technical Service request so my speculation that "as soon as I have time" means never is probably correct.

Since I haven't been able to get any help anywhere I might have to accept the fact that after about 25 years of programming on the Mac I am now an ex-developer.

I've had similar problems, which is why I found this thread. Unfortunately, I can see it's really just you streaming your journey through this problem without much help from the community. I suggest you supply some more information about your project.

It appears you are trying to compile a C file and are specifically talking about C headers. Have you tried looking at the preprocessor output? I once had the exact same problem and I discovered that my function name corresponded to a macro definition in some standard header. My function name was StrLength, so my function name was replaced by "int" in the preprocessor output. I added #undef StrLength and everything compiled fine.

In your case, your example is void func(...). Is that literally your code or is the function name something else? I suggest you include actual code if you the best help.

Is you project entirely comprised of only C files? Are you using Objective C? Are you bridging Objective C and Swift?

In my project, I have low level code in C. Then a layer of Objective C on top of that. Then Swift code for my model on top of that. Finally, there's SwiftUI code that uses the Swift model. In order to mix the Objective C and Swift, I needed a bridging header. I was getting hundreds of phantom errors at one point, even though my builds were successful. Turns out that it was related to the SwiftUI previews, which also are compiling the same code in its own builds.

I solved this problem by including more header files in the bridging file. I had included only the Objective C headers because the C headers were all included indirectly. I explicitly added all of the C headers and my phantom errors went away.

Believe me, I know how frustrating this can be! But you might get more help by providing more information about your project and supplying more actual source code.

The project has both C and Objective C source code files. XCode won't build either .c or .m files because it doesn't include the .h files in the target so the functions in the .c and .m files are undefined. Also there are a few other weird errors like: NSString - unknown type. This is probably also a no headers error.

There is no Swift.

On June 15th I changed the location or an NSTextField in a .xib. XCode blew up and never worked again in spite of my extraordinary efforts to fix it, checking everything, reading the documentation, rebuilding everything and even buying a new Apple Silicon Mac (which I needed to do anyway), knowing that there is not really any help for Mac developers.

It is VERY unlikely that there is a name collision. This project was created in about 2010 so it would have been obvious by now. Also if you add the same file to an xcodeproj twice it will generate a warning so it is likely that XCode will report this as an error.

Here is an example of real source code in a .h file:

#include <stdio.h>

void cocoaAlertForC(char *errorType, char *message);

XCode underscores the void declaration and reports Expected identifier or '(' - obviously a spurious error. It does this with or without the #include.

There's just no way to Force XCode to recognize header files in the Build folder with the old Project or in the target in the newly created project.

DTS is not interested in helping me.

I feel like I have to give up.

Good news: Apple DTS has responded to my request. I have already tried everything he suggested and more so I'm not optimistic but at least he can try to see if my projecs will **** up on his machine.

I'm assuming that when you say "...it doesn't include the .h files in the target...", you mean click on the file in the project navigator and then click on the Target Membership checkbox in the info pane. If that is what you mean, I can tell that you do not do that with header files. I'm using Xcode 14.3 and it won't even let me. You also don't do that with the Info file, although for some reason Xcode lets me, but that causes build problems.

It seems like you've somehow screwed up the paths to your files. Personally, I keep my implementation and header files together in the same folder. (I know some old school programmers like to keep them separated by file type.) I also group my files in the navigator to match the subfolders containing the files. That's how I maintain my sanity. So in my project that is only Objective C and C (no Swift), it looks like this:

And clicking on that small right pointing arrow icon after the filename takes me to the file in the Finder. I think that's key. If you click on that arrow and it doesn't take you to the actual file then something is screwed with your paths.

That aside, you've obviously been writing C for awhile now and you must know that an error on a line does not mean that there is an error on that line. It's probably an error that came before that line in the compile. If you get the header file locations sorted out and still have this compile error then I would look at the preprocessor output. That is what is actually being compiled, not the source code you're looking at.

Also, compile just the C implementation file and follow the includes from the implementation file in the order they are included. There's probably a problem earlier in the compile of the implementation file.

I keep all of my source code files and header files together in groups in the project folder. I can delete them from the project and then drag them back into the project. They will appear in the project navigator but they won't build. Spurious error: Expected identifier or '(' in the headers and the analyzer thinks that the header file is not a member of any targets in the current scheme that build for analyzing. I tried to add some headers individually and check the target box to force XCode to include them in my project but as you say, you can't and shouldn't do this.

I didn't change the inclusion of any .h .c or .m files. These are in the project folder. Adding them using the several options won't fix this. On June 15th I moved an NSTextField in a .xib a few pixels. When I built the project it and all of my projects stopped working on three versions of XCode and two Macs - Intel and Apple Silicon. XCBBuildService - a component of XCode crashed at this time. On the new M1 iMac this is not happening.

To verify that it isn't the project files, I created a new project (several times) and started adding files, carefully following the directions in the XCode documentation. Of course the documentation is inaccurate, for example I couldn't add some illustrations to the project without putting it in a workspace. They won't build. I'll study your post and see if I've missed anything.

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