Why isn't ProjectName-Prefix.pch
created automatically in Xcode 6
?
Is the precompile header no longer needed ?
Where should I write the code that was in ProjectName-Prefix.pch
before ?
Why isn't ProjectName-Prefix.pch
created automatically in Xcode 6
?
Is the precompile header no longer needed ?
Where should I write the code that was in ProjectName-Prefix.pch
before ?
I suspect because of modules, which remove the need for the #import <Cocoa/Cocoa.h>
.
As to where to put code that you would put in a prefix header, there is no code you should put in a prefix header. Put your imports into the files that need them. Put your definitions into their own files. Put your macros...nowhere. Stop writing macros unless there is no other way (such as when you need __FILE__
). If you do need macros, put them in a header and include it.
The prefix header was necessary for things that are huge and used by nearly everything in the whole system (like Foundation.h
). If you have something that huge and ubiquitous, you should rethink your architecture. Prefix headers make code reuse hard, and introduce subtle build problems if any of the files listed can change. Avoid them until you have a serious build time problem that you can demonstrate is dramatically improved with a prefix header.
In that case you can create one and pass it into clang, but it's incredibly rare that it's a good idea.
EDIT: To your specific question about a HUD you use in all your view controllers, yes, you should absolutely import it into every view controller that actually uses it. This makes the dependencies clear. When you reuse your view controller in a new project (which is common if you build your controllers well), you will immediately know what it requires. This is especially important for categories, which can make code very hard to reuse if they're implicit.
The PCH file isn't there to get rid of listing dependencies. You should still import UIKit.h
or Foundation.h
as needed, as the Xcode templates do. The reason for the PCH is to improve build times when dealing with really massive headers (like in UIKit).
TWAPIManager.m
, for example, to a another project, you'll get errors that TWALog()
is not defined, with no hint about where to find it. I've encountered exactly that problem on several large projects trying to share code. Creating TWAPILog.h
and importing it solves this with trivial dev cost. –
Scrawly UIKit
, though, what if you wanted to create a class that implements the UITableViewDelegate
protocol? Would you @import UIKit
for just that class, or would this be a necessary case for a PCH? Your answer, "as needed", isn't really clear. –
Friedcake NewRelic
calls in every single file? That would seem very strange. Looking at their docs, I only see one call required to their library (which is what I would expect). Have you tried without putting them in pch? –
Scrawly Without the question if it is proper or not, you can add PCH file manually:
Add new PCH file to the project: New file > Other > PCH file.
At the Target's Build Settings option, set the value of Prefix Header to your PCH file name, with the project name as prefix (i.e. for project named TestProject
and PCH file named MyPrefixHeaderFile
, add the value TestProject/MyPrefixHeaderFile.pch
to the plist).
TIP: You can use things like $(SRCROOT)
or $(PROJECT_DIR)
to get to the path of where you put the .pch
in the project.
At the Target's Build Settings option, set the value of Precompile Prefix Header to YES
.
I suspect because of modules, which remove the need for the #import <Cocoa/Cocoa.h>
.
As to where to put code that you would put in a prefix header, there is no code you should put in a prefix header. Put your imports into the files that need them. Put your definitions into their own files. Put your macros...nowhere. Stop writing macros unless there is no other way (such as when you need __FILE__
). If you do need macros, put them in a header and include it.
The prefix header was necessary for things that are huge and used by nearly everything in the whole system (like Foundation.h
). If you have something that huge and ubiquitous, you should rethink your architecture. Prefix headers make code reuse hard, and introduce subtle build problems if any of the files listed can change. Avoid them until you have a serious build time problem that you can demonstrate is dramatically improved with a prefix header.
In that case you can create one and pass it into clang, but it's incredibly rare that it's a good idea.
EDIT: To your specific question about a HUD you use in all your view controllers, yes, you should absolutely import it into every view controller that actually uses it. This makes the dependencies clear. When you reuse your view controller in a new project (which is common if you build your controllers well), you will immediately know what it requires. This is especially important for categories, which can make code very hard to reuse if they're implicit.
The PCH file isn't there to get rid of listing dependencies. You should still import UIKit.h
or Foundation.h
as needed, as the Xcode templates do. The reason for the PCH is to improve build times when dealing with really massive headers (like in UIKit).
.pch
file clean, but I'm confused in some situation, e.g. I use SVProgressHUD
, almost all ViewController
need to call it, so should I import SVProgressHUD.h
in every ViewController
? or create a BaseViewController
and import SVProgressHUD.h
? Category
s have the same situation. Could you give me any suggestion? –
Rimarimas TWAPIManager.m
, for example, to a another project, you'll get errors that TWALog()
is not defined, with no hint about where to find it. I've encountered exactly that problem on several large projects trying to share code. Creating TWAPILog.h
and importing it solves this with trivial dev cost. –
Scrawly UIKit
, though, what if you wanted to create a class that implements the UITableViewDelegate
protocol? Would you @import UIKit
for just that class, or would this be a necessary case for a PCH? Your answer, "as needed", isn't really clear. –
Friedcake NewRelic
calls in every single file? That would seem very strange. Looking at their docs, I only see one call required to their library (which is what I would expect). Have you tried without putting them in pch? –
Scrawly You need to create own PCH file
Add New file -> Other-> PCH file
Then add the path of this PCH file to your build setting->prefix header->path
($(SRCROOT)/filename.pch)
$(PRODUCT_DIR)/$(PRODUCT_NAME)/PrefixHeader.pch
–
Kingmaker I'll show you with a pic!
Add a new File
Go to Project/Build Setting/APPl LLVM 6.0-Language
To add .pch file-
1) Add new .pch file to your project->New file->other->PCH file
2) Goto your project's build setting.
3) Search "prefix header". You can find that under Apple LLVM.
4) Paste this in the field $(SRCROOT)/yourPrefixHeaderFileName.pch
5) Clean and build the project. That's it!!!
If you decide to add a .pch file manually and you want to use Objective-C just like before xCode 6 you will also have to import UIKit and Foundation frameworks in the .pch file. Otherwise you will have to import these frameworks manually in each header file. You can add the following code anyway as it tests for the language used:
#ifdef __OBJC__
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#endif
For add new PCH file follow bellow steps :
(1) Add New fiew - Select iOS - Other and PCH File
(2) add path of this PCH file to your Project - BuildSetting - Apple LLVM 6.0 Language
Add Set Prefix Header Path YourApplicationName(root-path)/filename.pch
Use :
$(PROJECT_DIR)/Project name/PrefixHeader.pch
© 2022 - 2024 — McMap. All rights reserved.
.pch
file clean, but I'm confused in some situation, e.g. I useSVProgressHUD
, almost allViewController
need to call it, so should I importSVProgressHUD.h
in everyViewController
? or create aBaseViewController
and importSVProgressHUD.h
?Category
s have the same situation. Could you give me any suggestion? – Rimarimas