.pch
#ifdef __OBJC__
#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>
#import "thing.h"
#endif
I have a pretty large project I'm trying to debug and I have a suspicion the problem is in thing.h
From what I understand the .pch file is included in EVERY .m and .h in the project.
Is it possible to have it not included in just one or two files? For debugging I would like to not include thing.h in just one test file, but removing it from the .pch causes a cascading nightmare across the project.
This is a really old question but I just ran into this issue. I was able to solve the problem by wrapping the pch file with a ifndef SOME_NAME. Then in the project settings on each specific file I wanted it to not be included I added a compiler flag of -DSOME_NAME=1. Hope that helps someone in the future.
Related
QUESTION: What and where is the pre-compiled header file in an xcode project?
PROBLEM: I need help with xcode.
DISCLAIMER: I know nothing about xcode.
BACKSTORY: I have an app built with appcelerator, which builds an xcode project for me. Now I want to make it Citrix Ready which by this press release should be easy http://www.appcelerator.com/press-releases/citrix/ but < rant > they have no documentation on this, no one at appcelerator seems to care, and they say to use SO for support (which I did and it got me the peer pressure badge, yay!).< /rant >
So, since they suck I'm trying to do it myself directly in xcode and with a question that is acceptable within SO guidelines.
SITUATION: I'm up to step 3 of the steps to do this are listed on the Citrix website: http://docs.citrix.com/en-us/mdx-toolkit/10/xmob-mdx-dev-guide-overview/xmob-mdx-dev-ios-apps.html#par_anchortitle_33e5
Step 3: Revise a line of code in the pre-compiled header file in the app project to import WorxEnable.h from Worx.framework as shown in the following example
#ifdef__OBJC__
_
//import MDX extensions
#import <AVFoundation/AVFoundation.h>
#import <SystemConfiguration/SCNetworkReachability.h>
#import <Worx/WorxEnable.h>
#endif
I just don't know what or where the pre-compiled header file is.
Any help would be much appreciated.
I look forward to posting questions about steps 4 and 5 asking what those mean and how to do them:
Step 4: Add the following to “other linker flags” if they do not already appear:
Step 5: Add the following frameworks and libraries:
Thanks!
Hum, I think it's the .pch file.
If it not exist in your Xcode project (Xcode does not create automatically this file now), create one like myproject-Prefix.pch (just an example).
And in the build settings, add your file path in Prefix Header
My pch file :
#import <Availability.h>
#ifndef __IPHONE_4_0
#warning "This project uses features only available in iOS SDK 4.0 and later."
#endif
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import <MobileCoreServices/MobileCoreServices.h>
#import <SystemConfiguration/SystemConfiguration.h>
#endif
I have a problem
#import Foundation;
and I see:
#import vs #import - iOS 7
and I set "Enable Modules" to "YES"
and my problem is not solved
I got this warning in a zero-swift project whenever I tried to add the #import SafariServices; statement.
Solution:
Enable the modules. Go to the Target > Build Settings and set the Enable Modules (C and Objective-C modules) to YES.
OR
Note: I haven't verified this potential solution, but probably worthy of consideration if there are side effects caused by this solution.
Rather than enabling modules to entire project, we can enable modules for a specific file which is importing c++ file. Go to build phases -> Compile Sources -> Select the file -> Add compiler flag -fmodules
The possible cause is that you use Objective-C++. Then modules get disabled despite the proper build settings.
I've been mixing ObjC, ObjC++, C++, and Metal. Whenever I get the "use of #import when modules are disabled" I try
replacing:
#import Name;
with:
#import "Name/Name.h"
example, replace:
#import Metal;
#import MetalKit;
#import CoreVideo;
with:
#import "Metal/Metal.h"
#import "MetalKit/MetalKit.h"
#import "CoreVideo/CoreVideo.h"
It seems to work.
Check if you are using #import "ProductName-Swift.h" somewhere in .mm files or any other files other than objc files.
Because if you use this import in cpp files then modules gets disabled automatically.
I am facing an issue, Currently i am using xcode 5.0, when i am importing clasess from prefix.pch then it dose not give suggestions on appdelegate.h file. But it gives suggestion on other view controller's. I have googled about it and find if we define macros in prefix.pch then this problem occurred. Still after removing the macros it did not give suggestion on appdelegate.
Suggestios means if i try to write
#property(strong,nonatomic) UINavigationController *navControler;
After writing #property(strong,nonatomic) UINav xcode did not give suggestion. But if I remove all the import statement and macros from prefix.pch file then xcode give suggestions on appdelegate.
From my point of view, rather than finding a workaround, I want to put some light on the actual problem.
So when you want to add something in .pch (pre compiled headers), it means you want to use the content of files before your program is actually being compiled & build. In simple words the headers included in pch acts as a stub code, a base code or may be a code that is meant for using as it is intact.
So if you have already included appDelegate.h file in .pch & writing some code in appDelegate.h file, then the compiler is trying to use 'appDelegate.h` from .pch as a pre-compiled information. And may be it is resulting in a indefinite sate of Xcode background processing, which is not allowing to show the drop down helps in the file which is already pre-compiled.
To me it looks like app delegate.h in .pch is not the right place. Where ever you want in your program, you can very well include appDelegate.h file. However it is also a signal of bad Class Design approaches.
Also, if you want to add #define statement & other macros in .pch then it is not the right approach. The right approach is :
Make a simple .h file, say constants.h
Add all your #defines & macros here in constants.h file.
Add the #import "constants.h" in your .pch file.
That should solve your problem.
Hope that helps.
I have a workspace and I'm trying to add Core Data to it. I went to the project I want to add Core Data to, selected the Target, hit the + sign under Link Wit Binary Files and added the Core Data framework. That part works fine. I can build and run. When I try the next and using this line:
#import <CoreData/CoreData.h>
I get build errors. These build errors look like:
"ARC Semantic Issue"
Pointer to non-const type 'id' with no explicit ownership
These errors are present in
NSEntityDescription.h
NSManagedObjectModel.h
NSMnagedObject.h
NSManagedObjectContext.h
NSPersistentStore.h
Does anyone know why I'm not able to import Core Data to an existing iOS project? Thanks in advance!
In my framework search paths, I had an erroneous path that correctly built once I removed it:
$(DEVELOPER_DIR)/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks
It should be as simple as adding CoreData.framework to your target:
Click the plus button (+) under Linked Frameworks and Libraries
Then in your Prefix file (Tabs-Prefix.pch in this case) in the #ifdef __OBJC__ declaration:
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#impport <CoreData/CoreData.h> //Added core data here
#endif
If this does not work, perhaps you have an older version of Xcode installed and the paths are messed up. It could be trying to import an older framework.
I think this could be related to your entity definitions. Is it possible that you have declared entities that use the attribute name id? That would typically be a NSNumber type in the model subclasses, i.e. *id.
It seems that in this case, the compiler instead of complaining about the *id in the class files, it indicates the id in the header files, which is confusing.
--> Try changing your attribute names.
I had the same problem. It was solved by the following steps:
Remove Reference to CoreData.framework from Frameworks group in Xcode.
Remove CoreData.framework from 'Link Binary with Libraries' in target settings.
Quit Xcode (Cmd + Q).
Open your project folder in Finder and delete CoreData.framework file.
Start Xcode, open your project. Now you may to add the CoreData.framework in 'Link Binary with Libraries'.
Don't forget to add #import <CoreData/CoreData.h> into <projectName>-Prefix.pch located at Supported Files. My prefix header seems like this:
`
#import <Availability.h>
#ifndef __IPHONE_5_0
#warning "This project uses features only available in iOS SDK 5.0 and later."
#endif
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import <CoreData/CoreData.h>
#endif
`
I don't know how existance of any file in project directory can affect to compile errors, but it works for me.
Hope this helps for anyone who reads it.
I am just wondering, is it good practice to include commonly/mostly used header files in .pch file?
e.g Most of files required below headers
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
So instead of each file should have, is it good practice to add those in .pch file?
.pch file
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import <MostlyUsed.h>
#endif
I found some disadvantages of this,
1) Dependancies get hidden.
2) Source files can not be copied directly.
It will be great if you guys provide some inputs on this.
Thanks
Yes you can do it.
Even it reduces compile time.
An Extract from In Objective-C, importing same headers in every class make compile time longer?
In general, newly-generated iOS projects come with this functionality,
which is called a precompiled header or prefix header, and is a file
that has the extension .pch.
You can throw all the headers you want in there and Xcode will
pre-compile it before it builds anything else, and use it to compile
the other compilation units in your project (e.g. .m files).
Using a precompiled header may or may not increase compile time; in
general, it reduces compile time, as long as you have a lot of common
headers and/or a lot of source files.
However, it's not necessarily good practice to treat the pre-compiled
header like a big dumping ground, as your compilation units can form
implicit dependencies on all sorts of stuff when you may want to
enforce loose coupling between components.
It is certainly a good practice as it reduces compile time and code is lot more manageable by doing so.