May 30, 2012 at 02:05A few words about Header Map in Xcode
The C / Objective C / C ++ language family needs a preprocessor. The preprocessor passes the compiled source through itself before passing the text to the compiler. Perhaps the most important part of the preprocessor’s job is to substitute the directives for the
The classic answer is this: the preprocessor sequentially iterates over the paths in INCLUDE_PATH starting from the first. The relative path from the include directive is resolved relative to the (sic) folder from INCLUDE_PATH. If the file is not found, go to the next INCLUDE_PATH element. If INCLUDE_PATH is exhausted, the compiler reports an error.
But Apple, as always, is making adjustments. When assembling in Xcode, the so-called header map . This is the index of all the header files in the project. If Xcode “knows” about foobar.h, then this file will be available simply by name ( ), regardless of the actual location on the file system. This is a great solution - as long as it works as intended. Unfortunately, the header map mechanism is poorly documented, which does not contribute to the quick resolution of problems. I will try to fill this gap.
But what if a project uses several header files with the same name? With the default settings, only one of these files will get into the index - which one cannot be predicted. The same problem occurs when the file name in the project matches the system header file, case insensitive (ex:)
For diagnostics, it may be useful to look into the generated header map. This is a binary file with confused optimization of common substrings. It’s good that kind people wrote a program for converting to text format.
Here
If c
PRODUCT_NAME is used as a prefix, and if you change it, the old prefix will still be in the header map (appears on 3.2. 5, possibly fixed in new versions). It is treated by closing-opening of the project.
Full list of settings .
#include<имя-файла>contents of the specified file. A relative path (: ex usually indicate stdio.h, sys/stat.h). A logical question arises - how does the preprocessor find the header files? The classic answer is this: the preprocessor sequentially iterates over the paths in INCLUDE_PATH starting from the first. The relative path from the include directive is resolved relative to the (sic) folder from INCLUDE_PATH. If the file is not found, go to the next INCLUDE_PATH element. If INCLUDE_PATH is exhausted, the compiler reports an error.
But Apple, as always, is making adjustments. When assembling in Xcode, the so-called header map . This is the index of all the header files in the project. If Xcode “knows” about foobar.h, then this file will be available simply by name ( ), regardless of the actual location on the file system. This is a great solution - as long as it works as intended. Unfortunately, the header map mechanism is poorly documented, which does not contribute to the quick resolution of problems. I will try to fill this gap.
#includeHeader map
Header Map definition is an index file generated by Xcode. The file is named after the current target and has the extension ".hmap". An index is a set of string key-value pairs. The index is used to match the full path to the header file by the argument of the directiveinclude. Index search is not case sensitive. Index search takes precedence over INCLUDE_PATH. This is done to speed up assembly.
By default, the header map is active. To disable, you need to create a variableUSE_HEADERMAP=NOin the project configuration.
But what if a project uses several header files with the same name? With the default settings, only one of these files will get into the index - which one cannot be predicted. The same problem occurs when the file name in the project matches the system header file, case insensitive (ex:)
Time.h.View Header Map
For diagnostics, it may be useful to look into the generated header map. This is a binary file with confused optimization of common substrings. It’s good that kind people wrote a program for converting to text format.
python headermap.py build/hmap.build/Debug/primary.build/primary.hmapHere
primaryis the name of the target.bar.h /Users/nickz/hmap/bar.h
foo.h /Users/nickz/hmap/foo.h
primary/foo.h /Users/nickz/hmap/foo.h
If c
foo.hand bar.heverything is more or less clear, then it primary/foo.hraises questions. As it turned out, Xcode creates such records for header files that are members of the current target. (In order for Xcode to allow the header files to be included in the target, you need to add copy headers build phase to it.) PRODUCT_NAME is used as a prefix, and if you change it, the old prefix will still be in the header map (appears on 3.2. 5, possibly fixed in new versions). It is treated by closing-opening of the project.
Settings
USE_HEADERMAP = [YES] / NOOn off.
HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT = [YES] / NOInclude header files that are members of the active target in the header map. At 3.2.5 is ignored .
HEADERMAP_INCLUDES_FRAMEWORK_ENTRIES_FOR_ALL_PRODUCT_TYPES = [YES] / NOInclude header files that are members of the active target in the header map. Files get a prefix
$(PRODUCT_NAME)/. If the setting is - YES, such records are created for any type of purpose; otherwise, only if the target type is Framework.HEADERMAP_INCLUDES_PROJECT_HEADERS = [YES] / NOInclude in the header map all the header files from the project without regard to goals. At 3.2.5 is ignored .
Full list of settings .
