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 ?
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).
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)
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
Use :
$(PROJECT_DIR)/Project name/PrefixHeader.pch
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
Related
the Dropbox iOS SDK has its own Framework bundle but in order to customize it easily I ve chosen to include its Xcode project as a subproject.
How should i refer to its .h classes?
I ve added the .xcodeproj from the "Add files" button and I ve added in the Header Search Path the following value:
$(PROJECT_DIR)
The subproject looks to be at the same level with the main project.
Shouldn't the importing itself link the dependencies?
(I m really frustrated by the import system in Xcode)
Your basic approach seems sound (and is pretty close to how I handle lots of vendor projects). Since you've added $(PROJECT_DIR) to your header search path, and assuming that the framework is in a directory named "Dropbox", then you can refer to the packages a couple of ways:
#import <Dropbox/Header.h>
#import "Dropbox/Header.h"
I prefer to think of the sub-projects as "system-like" and so tend to use angle-brackets, reserving double-quotes for internal code. But either approach is really fine.
Shouldn't the importing itself link the dependencies?
No. You still need to link the dependencies. #import does just exactly one thing: inserts the requested file into the current file. That's all it does. It is identical to you taking the referenced file and copy/pasting it into your code (that's basically how it's implemented in the pre-processor). That this is used for "header" files is a matter of convention. It has nothing to do with how the compiler works. You technically could import a .m file that included a method in it as a way to do code reuse. (I've seen that done in projects I've worked on. Please don't do this....)
When dealing with ObjC modules, it's a little different (using #import rather than #import). But if you're just importing headers as you seem to be, think of it as "stick this other file right here, exactly as written."
I want to include an Objective-C project (https://github.com/soffes/ssziparchive) into my Swift Project so that I can include the SSZipArchive into my project. I need this so I can unzip a file. As included in the instructions on the Github, I included the folder minizip, SSZipArchive.h, and SSZipArchive.m into my project. I have also created a bridging header where I included the following import into my project #import "SSZipArchive.h". However, when I try to type SSZipArchive on Xcode, the autocomplete doesn't occur, leading me to believe that SSZipArchive isn't included properly in my project. Any ideas on how to do so? I have already looked at numerous links on how to include Objective-C projects into Swift and I have found that I simply need to include the corresponding header files for my project to work.
I guess that you haven't set bridging header path properly. It's a very common problem, but easy one to fix.
Go to the Project Settings -> Build Settings -> Search, and search for bridg, and under Objective-C Bridging Header set the path of your bridging header file (carefully inspect it's path in Finder first, since it may be in some sub-directory of your project).
Also make sure that all your included header files have target of your application. To check if they have, click on the header file, open up Utilities from the right side and under Target Membership, make sure the first target is checked.
When X-code tries to create a bridging header automatically, it crashes every single time, so I followed the instructions on how to manually create a bridging header.
(Create a .h file, name it <#PROJECT_NAME>-Bridging-Header.h, import all the .h files you need?)
Problem is, when I try to instantiate a class in the .swift file that's included in that header, nothing happens (it says that class doesn't exist) Also, in the Bridging Header it doesn't seem to autocomplete my filenames when I try to include them, leading me to believe somethings not linking properly.
Has anyone run into this? Does anyone know how to fix it?
You need to add it to your target's build settings:
In Xcode, if you go into the build settings for your target, and scroll all the way down you'll find a "Swift Compiler - Code Generation" section.
Set "Objective-C Bridging Header" to <#PROJECT_NAME>-Bridging-Header.h
I'm not sure of the correct value for "Install Objective-C Compatibility Header", but it's a yes/no, so you can toggle that if it doesn't work at first.
I tried to create a bridging header myself but for some reason Xcode didn't like it.
So i deleted my custom one, imported an Obj C file which made Xcode ask if I wanted it to create one for me.
I clicked yes, and it worked!
1) create a file called "FMDB-Bridging-Header.h"
inside this file type the following:
#import "FMDB.h"
3) go to Build Settings -> Swift Compiler - Code Generation
- add to 'Objective-C Bridging Header': FMDB-Bridging-Header.h
or if it was placed inside a folder in your project:
FolderName/FMDB-Bridging-Header.h
Add a header file to your project with the name "[your-project-name]-Bridging-Header.h
Go to Build Settings > Build Options and set "Embedded Content Contains Swift Code" to "Yes"
Go to Build Settings > Linking and add "#executable_path/Frameworks" to Runpath Search Paths
Build your project now!
it could help setting the name of the bridging header with its Project root, as "MyProject/MyProject-Bridging-Header.h" into the string value of the Swift Compiler Build key 'Objective-C Bridging Header'
So many developers are adding various convenience macros to the Prefix.pch. But my question is what is that Prefix.pch file.
If i remove that Prefix.pch file from my Xcode, then will my application run? Or will it show any error? Or will it crash during build?
How can i run my application without Prefix.pch file
Precompiled header.
What is it?
A Prefix.pch is a precompiled header. Precompiled headers were invented to make compiling faster. Rather than parsing the same header files over and over, these files get parsed once, ahead of time.
Xcode
In Xcode, you add imports of the header files you want in a “prefix header,” and enabling Precompile Prefix Header so they get precompiled. But the idea behind a prefix header is different from precompiling.
A prefix header is implicitly included at the start of every source file. It’s like each source file adds
#import "Prefix.pch"
at the top of the file, before anything else.
Removing it.
You can remove the precompiled header. This question has been already answered in thread I'm linking below. It contains all the information you need as well as useful comments.
Is it OK to remove Prefix.pch file from the Xcode project?
What is Prefix.pch file?
A .pch is a Pre-Compiled Header.
In the C and C++ programming languages, a header file is a file whose text may be automatically included in another source file by the C preprocessor, usually specified by the use of compiler directives in the source file.
Prefix headers are compiled and stored in a cache, and then automatically included in every file during compilation. This can speed up compilation, and lets you include a file without adding an import statement to every file using it. They are not required, and actually slow compilation whenever you change them.
Yes, you can compile and run the project without .pch file
In Xcode, go to your target's build settings (Command-Option-E, build tab) and uncheck Precompile Prefix Header (GCC_PRECOMPILE_PREFIX_HEADER). You can also remove the value of the Prefix Header setting if you wish.
Also note that,
Don't put macros in a.pch file! A .pch file is, by definition, a project specific precompiled header. It really shouldn't be used beyond the context of the project and it really shouldn't contain anything but #includes and #imports.
If you have some macros and such that you want to share between headers, then stick 'em in a header file of their own — Common.h or whatever — and #include that at the beginning of the .pch
Prefix headers are compiled and stored in a cache, and then automatically included in every file during compilation. This can speed up compilation, and lets you include a file without adding an import statement to every file using it. They are not required, and actually slow compilation whenever you change them.
Generally .pch file naming formation is yourProjectName-Prefix.pch
Prefix Headers and Precompiled Headers (.pch)
History:
[#include -> #import] -> Precompiled Headers .pch -> [#import Module(ObjC);] -> [import Module(Swift)]
Precompiled Headers - prefix.pch
To create new .pch file
File -> New -> File... -> PCH File
PrefixHeader.pch sample:
#ifndef PrefixHeader_pch
#define PrefixHeader_pch
#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#endif
From Xcode 6 you should set .pch manually. Previously it was called <product_name>-Prefix.pch
Xcode:
Prefix Header(GCC_PREFIX_HEADER) - path to .pch. Adds all content from .pch to all source files
SomeFile1.h
//You can skip this section. It will be compiled
//#import <UIKit/UIKit.h>
//#import <Foundation/Foundation.h>
//implicitly next line is used
#import "PrefixHeader.pch"
Precompile Prefix Header(GCC_PRECOMPILE_PREFIX_HEADER) - When Yes then Prefix headers from GCC_PREFIX_HEADER will be used once* to generate precompiled sources and will be stored in a cache which speeds up a build time
//path to cached precompiled headers
/<some_path>/DerivedData/ExperiementsModuleSwift-dsetoksxykdmgvczgtnmaqmjwhzk/Build/Intermediates.noindex/PrecompiledHeaders/SharedPrecompiledHeaders/14385052922615550324
//e.g
/Users/alex/Library/Developer/Xcode/DerivedData/ExperiementsModuleSwift-dsetoksxykdmgvczgtnmaqmjwhzk/Build/Intermediates.noindex/PrecompiledHeaders/SharedPrecompiledHeaders/14385052922615550324
#import vs .pch
This feature improves build time(comparing with #include/#import) because precompiles a prefix headers(global). When some content of prefix headers is changed it means that Compiles must recompile that again. that is why you should use stable(not often changeable) prefix headers here or you dont't see build time improvement. Also you should support it
I often see open source code importing third-party libraries in Xcode / Objective-C implementation files like this:
#import <ThirdPartyLibrary/utilities.h>
but when I drag & drop the file structure and files of such a library in my project, all these imports are corrupted and Xcode does not know where the files are.
I end up hand-modifying every import to look like:
#import "utilities.h"
And include appears it is relative to the current physical folder on the file system. When a library split its files in folders on file system and I drag-drop it in Xcode, Xcode creates groups for the folders. But for import, I have to specify the folder name. Problem is when I am in a folder, for example:
http/httpTools.h
Then when httpTools.h wants to import utilities.h from the root, I have to change
#import <ThirdPartyLibrary/utilities.h>
to
#import "../utilities.h"
which is a chore. After doing this for 5 hours I thought damn, there must be a better way. Can someone explain what is the secret to teaching Xcode a new framework location that can be imported with angle brackets? The framework btw is source code. Not compiled. Just the naked code.
Specify the include path using the compiler flag -I, or the Xcode build settings alias HEADER_SEARCH_PATHS. Of course, you can use build variables when doing so.
Just stumbled upon the same issue, there are two types of search paths in Xcode:
Header Search Paths
User Header Search Paths
If you add your own include folders into Header Search Paths, you can use angled brackets.