Adding C file causes pch error - objective-c

I have an XCode project with objective-C files. If I add a new (empty) C file and try to build, I get a large number of errors right away while building a precompiled header, in ProcessPCH step. The errors are "fatal error: Could not build module 'Foundation'", and things in Foundation.h not being found. Remove the C file and it builds again. What is going on, and how to fix it?
(XCode 5.0, OSX 10.8.4)
EDIT I have tried Clean and Clean build folder, no effect.
EDIT Setting Precompile prefix header = No results in a bunch of syntax errors instead, in stuff like NSObject.h (and other Foundation framework header).
EDIT User Cy-4AH figured it out: there needs to be #ifdef __OBJC__ around the whole pch file.

Surround #import's with preprocessor directive #ifdef __OBJC__ #endif

Related

How do I get the compiler to see my Framework module.modulemap umbrella header?

I am building a framework with mixed Objective-C and Swift source files.
I've created my own module map file named module.modulemap.
My problem is that the compiler compiles only my umbrella header file when I put in the absolute path:
How do I get the compiler/Xcode to see the header file?
Ok, so I've found the issue. (Or one of them). It seems that to be able to use an umbrella header, the header must be an actual header file. In this case I was just using the only header file in the project, which also had a .m file.
My solution was to create an actual UmbrellaHeader.h file with the following contents:
#ifndef UmbrellaHeader_h
#define UmbrellaHeader_h
#include "TestObject.h"
#endif /* UmbrellaHeader_h */
FYI: If your project has its Headers phase before Compile Sources and you try to create a mixed Objective-C/Swift framework, you can see Swift compiler errors about the umbrella header being missing. If you remove/rename all .swift files the project will build fine, then putting them back it will build a second time, but a clean build fails.
Just move the Headers phase earlier in the build process and it should work.

Objective-C ARC was enabled in PCH file but is currently disabled - Error

I am trying to convert my Objective-C Project to ARC. Once I add the -fno-objc-arc compiler flag to one or more individual files in Build Phases, my MyProject-Prefix.pch file shows the following error:
Objective-C automated reference counting was enabled in PCH file but is currently disabled.
You have to make sure that :
Compiler is set to Apple LLVM compiler 4.x
Project property : CLANG_ENABLE_OBJC_ARC is enabled (change it to YES)
You have cleaned your project (Product -> clean)
Following the steps above you will ensure that you have switched to ARC using the LLVM/clang compiler, if none of the above will solve the problem you can try disabling precompiled prefix unchecking Precompile Prefix Header (GCC_PRECOMPILE_PREFIX_HEADER) in XCode Build phases. The use of the PCH is not mandatory since is used to increase compilation time.

Why do Xcode templates have #imports that duplicate Prefix.pch?

While learning iPhone programming, every Xcode template I've seen includes an AppName-Prefix.pch file with the following contents:
#ifdef __OBJC__
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#endif
My understanding is that this file's contents are prefixed to each of the source code files before compilation. Yet each of the other files also imports UIKit, which seems superfluous. For example, main.m begins...
#import <UIKit/UIKit.h>
int main(int argc, char *argv[]) {
...
Cocoa applications in Mac OS X do the same thing, importing Cocoa.h in both the prefix file and the header files.
Why have both? I removed the #import directives from all of the source files except the prefix file, and it compiled and ran correctly.
My understanding is that this file's contents are prefixed to each of the source code files before compilation
That's basically correct but you need to understand the subtle points: Every compilation from Xcode eventually boils down to an invocation of gcc or clang. What XCode does is to compile the X.pch file first:
clang -x X.pch -o X.pch.gch
and then when an individual source file (say a.m) is compiled, it issues
clang -include X.pch a.m -o a.o
which loads the pch file, triggering the use of the precompiled header. So, from the point of view of the compiler, it's not really that the content of the pch file is automatically prefixed. Rather, Xcode prefixes the precompiled header to a file when it invokes the compiler.
A future version of XCode might just stop doing it. So, it's better to keep #imports in your .m or .h files, too.
You can also think of it this way: the use of the pch file is just what Xcode does for us behind the scenes to speed up the compilation process. So, we shouldn't write codes in a way it essentially depends on it, like not importing UIKit.h file from our .m/.h files.
(Also, it seems to me that XCode4's syntax coloring gets confused if you don't import the appropriate header files correctly from the .h and .m files.)
Why have both?
Better safe than sorry. Precompiled headers can be disabled, and since #import won't import anything twice, the overhead is negligible.

How to compile specific files in objective-c++ and the rest of the project in objective-c

I'm currently busy on a project where I need to use an external accessory to read Mifare 1k tags.
The accessory was provided with an SDK, written in (Objective ?)C++ and I followed the instructions provided to set XCode to "Compile sources as: Objective-C++" and added "-Obj-C++" in "Other linkers flags.
The SDK compiles fine then, but trouble is I am already using several libraries in the project (such as ASIHTTPRequest, JSONKit, ...) and I get compilation problems because of those new settings in those libraries. If I switch back to the previous settings, I get compilation problems in the reader's SDK
The question is: is there a way to compile only the class from the SDK as C++ and the rest of the project as objective-c ?
Edit: the SDK files consists only of .h (and a linked library)
thanks for your help,
Mike
Select the file you want to compile as Objective C++ from the file navigator, and then select the File Type in the file inspector view. This is in Xcode 4, but there is a similar mechanism in Xcode 3.
Try renaming the files where you are including the library headers to myClass.h for interface and myClass.mm for implementation files. This forces the files to be compiled as objective-c++.
I have resolved this problem:
You should set "According to file type" to "Complile Sources As",
Set "-ObjC++" to the "Other Linker Flags"
The last,you should modify the files's suffix to .mm that reference
the library method
well, in Build phases tab, there is a section Compile sources. For file you want to use Objective-C++ compiler add flag: -xobjective-c++
tested in Xcode 12.5

GNUStep make with a precompiled (and prefixed) .pch header from Xcode project?

I'm trying to build an Xcode project with GNUStep-make. Right now the project is very small (3 classes) however it will grow to hundreds of classes over the coming weeks so I'm trying to get everything figured out and well-organised now.
Xcode creates a ProjectName_Prefix.pch file which is a header that: a) get precompiled and b) is prefixed to every file in my project; at least if I understand correctly.
Now, how do I tell GNUStep-make what to do with this file when it builds? I've added it to the XXX_PRECOMPILED_HEADERS variable.
Cioccolata_OBJC_PRECOMPILED_HEADERS = Cioccolata_Prefix.pch
With this in place the build fails with the error:
Making all for framework Cioccolata...
make[1]: *** No rule to make target `/Users/chris/Projects/Mac/Cioccolata/build/GNUStep/obj/PrecompiledHeaders/ObjC/Cioccolata_Prefix.pch', needed by `internal-precompile-headers'. Stop.
make: *** [Cioccolata.all.framework.variables] Error 2
I've also got the following in my makefile:
ADDITIONAL_OBJC_FLAGS += -include Cioccolata_Prefix.pch -Winvalid-pch
I'm not sure what I've done wrong here. I basically have tried to follow the GNUStep documentation for precompiled headers.
None of my project's source files expressly include the Foundation framework since this header does that.
Thanks for pointing our attention to this problem and for your patch! :-)
This is now fixed on gnustep-make trunk, and so will be fixed in gnustep-make 2.4.0 once released.
Nicola Pero (gnustep-make)