xcode相关的一些知识(一)

xcode相关的一些知识(一)

(2012-01-06 13:44:59)


转载▼

标签： 转载

原文地址：xcode相关的一些知识(一)作者：jetKill

1.修改xcode下键盘的一些快捷键

Choose Xcode > Preferences.

Select Key Bindings, which lets you change the keyboard shortcuts for actions accessible through menu items or the keyboard, such as paging through a document or moving the cursor. You can choose a predefined set of keyboard shortcuts for menu items and other
tasks, or you can create your own set.

2.添加breakpoint的action

Normally, Xcode just stops the execution of the program when it encounters a breakpoint. By specifying breakpoint actions, you make Xcode perform other actions, such as logging output to the
console.

To add a breakpoint action to the breakpoint you added earlier:

Choose Run > Show > Breakpoints. Xcode displays the Breakpoints window.

In the detail view in the Breakpoints window, click the triangle to the left of the breakpoint you added earlier.

Click the add (+) button that appears below the breakpoint.

From the pop-up menu that appears in the line below the breakpoint, choose Sound.

From the second pop-up menu, choose the sound you want Xcode to play when it reaches that breakpoint.

Now when execution reaches the breakpoint, Xcode plays a sound in addition to stopping the program.

3.在xcode的Groups&Files列表中，有一项Excutables，Excutables是什么？

After you’ve successfully built a product, you need to test it to make sure that it works. When it comes time to run or debug your product, you use an executable environment to tell Xcode how
to do so. An executable environment tells Xcode what program to launch when you run or debug from within Xcode and how tolaunch the program. The executable environment lets you tell Xcode what command-line arguments to pass, what
environment variables to set, what debugger to use, and so forth.

If you are building a product that can be run on its own—an application, command-line tool, and so forth—Xcode automatically sets the default executable to the target’s product. However, if you have a product such as a plug-in or framework, you must create
an executable environment to specify a program to run and test your product with.

Even if your product generates an executable that can run on its own, you may want to customize the executable environment to specify command-line arguments for Xcode to pass to the program on launch, environment variables to set, and so forth.

A project can contain any number of executables. There is not a one-to-one correspondence between targets and executables, although Xcode automatically creates an executable environment for each target that creates a product that can be run on its own. You
can, however, define multiple executable environments to use to test the product of a single target under different circumstances.

4.修改product的location
Each time you create a project, Xcode sets the build locations for that project to the default build locations
specified in the Building pane of Xcode preferences. You can, however, override these default build locations on a per-project basis. By taking advantage of this feature, you can choose default build locations that works best for most of your projects, and
specify other default build locations for individual projects as needed.

In the Groups & Files list of the project window, select the project group and then click the Info button in the toolbar.

Click General to see the current build location.

Change the location of the build products by selecting “Custom location”, clicking Choose, and navigating to a location.

5.什么是project root?
在project info->General中，有一个叫做Roots的属性。
A project root is a directory containing a project package (xcodeproj文件), source
files, and other project files. Simple projects have a single project root. Complex projects, made up of two or more projects that share products or resources, can contain multiple project roots. Each project root has its own SCM configuration, which allows
you to work on projects made up of multiple projects with subprojects stored in different SCM repositories.
6.什么是Project format？
在project info->General,有一个Project format.Project
format specifies the Xcode release with which the project must remain compatible.
You may work in a team in which some team members may need to use an Xcode release different from the one
you use; for example, some developers may need to use Xcode 2.4 while you may want to use Xcode 3.2 to take advantage of features that are not available in earlier releases. If you use Xcode 3.2 to work on the same projects that an Xcode 2.4 user also works
on, you have to make sure that you don’t use Xcode 3.2 features on those projects; otherwise, your Xcode 2.4–using colleague may have trouble working on or even opening the projects.When
you choose a project format that doesn’t support the project configuration (for example, when a build setting isn’t supported by the chosen format), Xcode notifies you of the incompatibility .To
view the details of the incompatibility, click the Show Conflicts button (this button is available only when there’s at least one conflict).You
have two options for solving these conflicts:

Change the project format to one that supports the feature that’s causing the conflict.

Other developers working on the same project must use a release of Xcode that supports the same project format.

Change the project configuration so that it doesn’t use the feature that’s causing the conflict.

7.什么是Organization name?
在project
info->General->Organization name. Specifies name of the organization to which copyright is attributed in header files created for the project.
In XCode 4, open up your project. Select the top-most item in the Project Navigator (MyProjectName,
1 target, iOS SDK 4.3 -- or whatever). Open up the file inspector (View->Utilities). In the Project Document section, you should see an "Organization" line. Edit that, and new files that you create will display the new organization name.
8.什么是Parallel target builds?
在project
info->General->Parallel target builds. Specifies whether to build independent targets in parallel.

Normally the build system builds a target’s dependencies sequentially; such builds are called sequential target builds). That is, each dependency’s build process is completed before starting
the build process for another dependency.

To shorten the build process, the build system can take advantage of parallel target builds. With parallel target builds, the build system builds target dependencies in parallel instead of one at a time.

The only build phase that the build system carries out in parallel is Compile Sources. All other build phases are performed linearly. This means that before and after the Compile Sources build phase, the build system processes a target’s dependencies sequentially.

Before activating parallel target builds for a project, ensure that the targets to be built in parallel do not have dependencies (direct or indirect) on each other. An example of an indirect dependency is a target that uses a source file generated during the
build process of another target. With sequential target builds, this hidden dependency may be avoided by building the target that generates the source file first. However, with parallel target builds, the order in which the targets are built is undetermined,
which may produce successful and unsuccessful builds of the same target with no changes made to it.

9.什么是Code Sense Index?
在project
info->General中，Allows you to rebuild the symbol index.

Symbol Indexing makes it simple to find and view information about your code and to gain easy access to project symbols. A project’s symbol index maintains detailed information about the code
in your project and in libraries used by your project; this information is stored in a project index. Using this project index, Xcode provides support for features such as the following:

Code completion. Code completion, assists you in writing code by providing completion suggestions from within the editor. Code completion uses the stored information about the symbols, as well as the contextual information
from your source code, to offer a list of classes, methods, functions, or other appropriate symbols for the code you are working on.

Class browser. Using the class browser, you can view the classes in your project and its included frameworks. From the class browser, you can easily access declarations, source code, and documentation for these classes
and their members.

Project Symbol smart group. The Project Symbol smart group allows you to view all of the symbols in your project directly in the project window. You can search these symbols or sort them according to type or name to
quickly find the symbols you need. The Project Symbols smart group also gives you easy access to a symbol’s definition.

Searching. Xcode offers numerous ways to search for symbols and other information in your project. For instance, you can perform a projectwide search for
symbol definitions, or you can select an identifier in an editor window and jump to its definition.

Xcode creates the a project’s symbol index the first time you open a project. Thereafter, the index is updated in the background as you make changes to your project. Indexing occurs on a background thread, to keep it from interfering with other operations in
Xcode. The index can be completely rebuilt, if necessary, by opening the General pane in the Project Info window and clicking the Rebuild Code Sense Index button.

Indexing is enabled by default. You can disable indexing for all projects that you open. To do so, choose Xcode > Preferences, click Code Sense, and deselect the “Enable for all projects” option in the Indexing section.

Note that if you turn off indexing, you will be unable to use those features that rely on the project index, such as code completion, the class browser, and the other features mentioned in this section. You can specify whether Xcode includes a particular file
in the project index using the “Include in index” checkbox in the File Info window.

10.Files in project

For each source file included in a project, Xcode tracks file attributes, such as the name and type, as well as other information. Below shows the information that Xcode tracks for
source files.
A
source file


In the illustration, the name is the file-system name for the file. The file type identifies the file as being one of several classifications (source file, image file,
text file, and so on.) Depending on the file type, Xcode stores additional information about the file, such as the file encoding, type of line endings, and so forth.

The path to the file specifies the file-system location for the file. The path type —which you can modify—indicates how Xcode stores the path; that is, whether it is
absolute or relative to the project directory or another location. You can view and edit these file attributes in the File Info window.

The project lets you pull together all of the files and other information required to build a set of related
software products. Within a project, you use a target to specify the files needed for an individual product. The files can reside at any location in your file system; they do not need to be placed in your project folder.

when you
want to add files or folders to your project, just drag the icons for the files or folders from the
Finder to the project window Groups & Files list, then Xcode displays a dialog:



Here is what the dialog contains:

The “Copy items into destination group’s folder (if needed)” option controls whether or not the files are copied into your project folder on disk. If you select this option, Xcode copies over any files that are not already present in the project folder. If
the project folder contains subfolders for groups, then the files are copied into the appropriate subfolder.

The Reference Type menu specifies how the location of the file is stored. Xcode stores the location, or path, for each file, framework, and folder in a project. Xcode uses this path to locate the item. Xcode can store this as an absolute path or relative
to another file-system location. You choose the way that a given file, framework, or folder is referenced when you add it to the project. You can also change the reference type for an item in the File Info window. Xcode supports the following reference styles,
each of which is available in the Reference Type menu:

Relative to Enclosing Group. The path is relative to the folder associated with the file’s group(group的意思是工程中的上层文件夹,比如Classes和Other Sources). If the file is not in a group or the group has no associated folder, the path
is relative to the project’s folder. This is the default setting for files in your project’s folder.

Relative to Project. The path is relative to the project’s folder, regardless of whether the file is in a group with an associated folder.

Relative to Build Product. The path is relative to the folder that contains the project’s build products. This reference style is the default for items that are created by one of the project’s targets.

Relative to <source path>. The path is relative to a user-defined source path. You can define a source path in the Source Trees pane of Xcode preferences. Note that this reference type is not available to you until you
have defined at least one source tree.

Absolute Path. The path is absolute from the root directory (/). This is useful in a limited set of circumstances, when you want to locate a file at a particular path. In most cases, you should use a relative path; absolute
paths are fragile and break easily when you move projects between computers.

If a file is inside your project folder or its build folder (created by Xcode when it creates a new project), use one of the first three reference styles.
If Xcode can’t find a file, folder, or framework at the path stored for it in the project, Xcode displays the item in red in the project window. Note
that this menu does not contain any source paths until you have defined one or more source trees in Source Trees preferences . After you have defined a source path, it appears at the bottom of the Reference Type menu and you can choose it for the files and
folders you add.A source tree is a root path that can be used to define a common location for target outputs. A source tree defines a name and a location
on the local file system. When you add files and folders to your project, you can specify their location relative to any source tree defined for your computer. Xcode stores the file reference relative to this source tree. Any users who have the same source
tree defined are able to work on the same project seamlessly, provided that the file also exists at the source tree location on their computers.

Source trees let you keep common resources in locations other than the project folder of an individual project and still transfer projects back and forth between team members and their various computers without breaking the project’s file references. This is
particularly useful if you have a set of common files or resources that are used in a number of projects and therefore cannot live in the project folder. Everyone working on a common project should have the same source trees defined; even though the locations
assigned to those source trees may differ, the names must be the same in order for Xcode to locate the necessary files and materials on the developer’s computer.

The source trees that you define are available to all your projects; that is, Xcode supports CodeWarrior-style global source trees. Because source trees are stored for each user, if you have multiple developers using a single computer, you will have to define
the source trees for each user, even though the location for those source trees is the same. After you have defined a source tree, it is available to you from the Add Files dialog to use when adding file, folder, and framework references to your project. You
can edit source trees in Source Trees preferences. To open this pane, choose Xcode > Preferences and click Source Trees. To add a source tree, click the plus (+) button beneath the source tree table. Xcode adds an entry in the table. Add the following information
to the entry:

Setting Name is the name of the source tree. This name must be the same for all users who wish to use this same source tree to refer to common files.

Display Name is the name that Xcode shows for the source tree in dialogs, Info windows, and anywhere else the source tree is used in the user interface. For example, this is the name used in the Path Type menu of the
File Info window.

Path is the full path to the files and other resources located using this source tree on the user’s system. This path may vary from computer to computer, and from user to user.

To delete a source tree, select the source tree in the table and click the minus (-) button. To edit a source tree, double-click the entry for the source tree in the appropriate table column and type the new text.

The Text Encoding menu specifies the encoding for the file or files.
The file encoding of a file defines the character set that Xcode uses to display and save a file. If you type a character that isn’t in the file’s encoding, Xcode asks whether you want to change the encoding. Xcode uses the default single-byte string encoding
or Unicode if the file contains double-byte characters.

To change the file encoding for one or more files:

Select the files and open a File Info window.

In the General pane, choose the desired file encoding from the File Encoding pop-up menu.

Generally Unicode (UTF-8) is best for source files and Unicode (UTF-16) is best for

.strings

files.

The Add To Targets group allows you to add the file to one or more of the targets currently defined in your project. If the checkbox next to a target name is checked, the file is added to that target when it is added to the project. When you add a file to a
target, that file is built when the target is built. You can specify which files are included in a target at any time; this option allows you to add the file to your project and to any necessary targets in one step.

The remaining options apply only if the selection of files to add to the project includes one or more folders. Xcode can add folders in two ways, as a group or by folder reference.

Group. Xcode recursively creates groups for the folder and its subfolders. Each of the files in these folders is added to the project and is placed in the group for the appropriate folder. If you choose to copy the files
into the project’s folder, Xcode duplicates the folder hierarchy. If you move a file to the folder outside of Xcode, Xcode does not add the file to the project.

To add a folder as a group, select “Recursively create groups for any added folders.”

Folder Reference. Xcode adds the folder itself to the project but not its contents. This is useful if you need to manipulate the folder as a whole but not the individual items within it. One example is a folder of help
files that you edit outside of Xcode and that you want Xcode to move into the application’s Resources folder when you build the application.

To add a folder as a folder reference, select “Create Folder References for any added folders.”

Each of your project’s targets specifies the frameworks and libraries against which its source files are linked. You can link against standard libraries or external libraries. Standard libraries
or frameworks are those provided by the active SDK. External libraries or frameworks are those not provided by the active SDK.

To add a library to a target:

Open the Info window for the appropriate target and click General.

The Linked Libraries list in the General pane lists the libraries against which Xcode links the target’s source files.



Click the Add (+) button below the Linked Libraries list.

Choose the library to add.

To add a standard library, choose the library from the dialog.



The dialog displays libraries and frameworks that belong to the target’s
Base SDK build setting, which is normally defined at the project level in the General pane of the Project Info window.

To add an external library, click Add Other.

After choosing an external library, Xcode presents the same options described in adding Files and groups. The following options apply to external libraries:

The Reference Type menu in the dialog specifies how the location of the framework is stored.

The Add to Targets group box allows you to add the library to one or more of the targets currently defined in your project. If the checkbox next to a target name is checked, the library is also included in that target when it is added to the project.

The Text Encoding menu specifies the encoding used for the files in a framework.

When using external libraries, you must ensure Xcode can locate the
appropriate headers using the Header Search Paths build setting(貌似同时也要设置Library Search Paths成该外部库的路径). All
headers in your project are automatically accessible to your source code. You can also specify additional search paths at which to find headers using the Header Search Paths (

HEADER_SEARCH_PATHS

)
build setting. Note that you do not have to add headers to your target to include them in your
source code. You should add header files to your target—as part of the Copy Header Files build phase—only if they are embedded in your product, as with a framework.By
default, Xcode searches user paths before system paths. This means that, by default, your project headers have precedence over system headers. Thus, if your project defines a header file named

String.h

,
source code in your project that includes

String.h

incorporates your project’s version of the header, not the system version. You can override this behavior by turning
off the Always Search User Paths (

ALWAYS_SEARCH_USER_PATHS

) build setting.When
Always Search User Paths is inactive, project headers can be incorporated into translation units only by surrounding the header filename with quotation marks. (A translation unit is a single source file with its imported/included
files). (A translation unit is a source file with its imported/included header files.) For example,

#include "String.h"

incorporates the

String.h

header
file defined in the project into generated translation unit. Furthermore, system headers can be incorporated into translation units only by surrounding the header filename with angle brackets. For example,

#include
<String.h>

incorporates the

String.h

system header file into the generated translation unit.

Xcode defines a number of build settings for specifying general search paths for files and frameworks used by targets in your project. These build settings are:

Header Search Paths (

HEADER_SEARCH_PATHS

)

This is a list of paths to folders to be searched by the compiler for included or imported header files when compiling C, Objective-C, C++, or Objective-C++ source files.

Library Search Paths (

LIBRARY_SEARCH_PATHS

)

This is a list of paths to folders to be searched by the linker for static and dynamic libraries used by the product.

Framework Search Paths (

FRAMEWORK_SEARCH_PATHS

)

This is a list of paths to folders containing frameworks to be searched by the compiler for both included or imported header files when compiling C, Objective-C, C++, or Objective-C++, and by the linker for frameworks used by the product.

Rez Search Paths (

REZ_SEARCH_PATHS

)

This is a list of paths to search for files included by Carbon Resource Manager resources and compiled with the Rez tool.

Xcode supports recursive search paths. For each path that you enter in one of these search path build settings, you can specify
that Xcode search the directory at that path, as well as any subdirectories that directory contains.

Xcode performs a breadth-first search of the directory structure at the search path, following any symbolic links. Xcode searches locations in the order in which they appear in the search paths table, from top
to bottom. It stops when it finds the first matching item, so if you have multiple files or libraries of the same name at the locations specified by a set of search paths, Xcode uses the first one it finds.

Note that adding very deep directory structures to a list of recursive search paths can increase your project’s build time. The maximum number of paths that Xcode expands a single recursive search path to is 1024.

4. Choose whether the library is required or optional.

Required libraries must be present on the host computer for the product to load. Optional or weak-linked libraries may or may not be present for the product to load; however, before accessing any of the library’s symbols at runtime, you must ensure that the
optional library is present on the host.

In addition to file, framework, and folder references, Xcode projects can contain a cross-project reference; that is, they can refer to another project outside of the current one. It is not always feasible or desirable to keep all related targets and products
in a single project. However, you may still need to reference targets or products that reside in a different project. For example, you may have several applications that rely on a common framework that resides in a different project. In this case, you can
add a reference to the project containing the framework to the project containing the application. This reference, called a cross-project reference, lets you access the targets and products of the referenced project
from your current project.

To create a reference to another project, choose Project > Add to Project and select the project package (the

.xcodeproj

file package) of the project
you wish to reference. (You may also drag the project group in the Groups & Files list of another project or a project package in the Finder to the current project’s project group.) Xcode adds a reference to the source group for your current project, visible
in the Groups & Files list. The project reference is identified by the Xcode project icon. Clicking the disclosure triangle next to the project reference shows the product references that the other project contains. These product references can be added to
targets in the current project.

You can relate targets in the current project to targets in the referenced project by creating a target dependency. You can add a dependency on a target in the referenced project in the same way that you would add a dependency to a target within the same project.

For projects that use cross-project references, you should use a common build location; doing so ensures that Xcode can automatically locate products created by targets in those projects.

cross-project reference的例子：

一个是产生静态库的工程A，另一个是需要使用静态库的工程B。

将静态库的Xcode项目加入到当前项目，



右击Targets下本项目，添加到静态库项目的关联。



在项目下，扩展静态库项目，拖动xxxx.a到Targets下的Link Binary With Libraries。



这样你就可以从当前项目下，双击静态库的项目来打开和修改静态库的代码了。

11.What's the Xcode Cache?

Xcode places its persistent caches in a secure location in your file system. You can get to this location using the

getconf

command:

> cd `getconf DARWIN_USER_CACHE_DIR`

This location is known as

<Xcode_Persistent_Cache>

.

If the Xcode cache grows too much, you can delete it using the Empty Caches command. Keep in mind that the Xcode cache may include precompiled headers for your projects, and building those projects may take longer after the cache has been emptied.

To empty the Xcode persistent cache, choose Xcode > Empty Caches.

12.Search text in a file

To search for text in a file that you have open in the editor, choose Edit > Find > Find.

You can ust Regular Expression to searche for text matching the regular expression in the search field.Xcode uses the ICU library for regular expression matching (see http://icu-project.org/userguide).

There is an option named Wrap around. Select this option to search the whole file; otherwise, Xcode searches from the current location of the insertion point to the end of the file.

13.Search in a project

When replacing text using regular expressions, instead of the dollar (

$

) sign to specify
references to capture-group text, use the slash (

) character.

For example, to specify capture group 0 in the replacement text, use

, not

$0

.

14.View the symbols in your project

When you select the Project Symbols group for a project, you get a view about all your symbols in your project.

15.View your class hierarchy in the class browser

If you are programming in an object-oriented language, you can view the class hierarchy of your project using the Xcode class browser. To open the class browser, choose Project > Class Browser. You can also open the class browser by selecting a symbol in the
Project Symbols smart group and choosing View > Reveal in Class Browser.

16.Per-File Compiler Flags

The build system provides facilities for customizing the build process of source files of particular types. It includes the Other C Flags (

OTHER_CFLAGS

),
Other C++ Flags (

OTHER_CPLUSPLUSFLAGS

), Other Warning Flags (

WARNING_CFLAGS

), and Preprocessor
Macros (

GCC_PREPROCESSOR_DEFINITIONS

) build settings, among many others, to customize the invocation of the compiler when processing C-based source files. However, sometimes
it’s necessary to specify compiler flags for particular files. For example, in a project that treats warnings as errors in general, you may have a set of cross-platform source files whose warnings you want the compiler to ignore.

To view the compiler flags for a file:

Select the source file in the Groups & Files list.

Choose File > Get Info to open the File Info window.

Display the Build pane .


The
Build pane of the File Info window is available only for files containing source code.

In the Additional Compiler Flags for Target field, you can enter any compiler flags you want to assign to the file. Use spaces to separate flags.

You can use multiple selection to assign compiler flags to a subset of the files in a target.

For each target that a file belongs to, Xcode maintains a separate list of compiler flags assigned to the file. To specify compiler flags for use with a file when it is built as part of a particular target, select the file from the appropriate build phase in
that target and open the File Info window, as described earlier. If you open an Info window for the same file from any other group in the project window, Xcode assumes you want to assign compiler flags to the file in the active target; thus, the Build pane
is available only if the file is part of the active target.The build system doesn’t validate the flags you add; that is, it doesn’t test whether the compiler actually supports the options you add, and it doesn’t investigate whether the options you add conflict
with the ones it generates. If you add a group of compiler options for a file that produce build errors or warnings, you should remove all the options you added and add them back one at a time, making sure the file compiles after you add each option, to determine
which option is not supported. You should also consult the tool’s documentation to learn about possible conflicts.The additional compiler options specified for a file are always used when the file is processed as part of a build.You can use file compiler options
to negate compiler options generated by the build system. For example, you may have turned on the Unused Variables build setting for your target, but want to deactivate unused-variable warnings for only one of the target’s source files.

To negate the effect of a build setting on a particular file:

Clean and build the target to ensure there are no build errors or warnings.

Using the build-setting descriptions in the Build pane of the project or target Info window, determine the compiler option that corresponds to the build setting in question.


3.Add
the negative form of the compiler option, by prepending it with

-Wno-

, to the compiler flags of the file whose build-setting effect you want to suppress.
For example, to negate the

-Wunused-variable

compiler option (which the build system generates when Unused Variables is turned on), add

-Wno-unused-variable

to
the file’s compiler options.4.Build the product. If there are build errors, the compiler option just added may not be
supported by the compiler.
17.Build a target
The first time you build a target, the build system creates all the intermediate
files, such as object files, needed to build the product. In subsequent builds of the same target, the build system processes only the files that have changed since the target’s previous build. For example, if the only change to the target since the last time
it was built was a minor edit to a single source code file, the build system recompiles that file and relinks the object files to create the finished product. That is, changes to the contents of the file and changes to build settings that affect the way a
source file is built cause the build system to rebuild the file.If you want to force Xcode to rebuild a build file the
next time you build the target, you can touch the file, to mark it as changed. Similarly, if Xcode has marked the file as needing to be rebuilt, but you know you haven't made any substantive changes to the file, you can untouch the file; the build system does
not rebuild the file the next time the target is built. To touch or untouch a file, click in the build status column (indicated by the hammer icon) next to that file in the detail view. If a checkmark appears in this column, the file is rebuilt the next time
you build a target to which it belongs. Keep in mind that this feature does not work with all build systems.
18.Build with xcodebuild

In addition to building your product from the Xcode application, you can use

xcodebuild

to build
a target from the command line. Building from the command line gives you additional flexibility compared to building from within the Xcode application that may be useful in certain circumstances. For example, using

xcodebuild

,
you can create a script that automatically builds your product at a specific time.

The

xcodebuild

tool reads your

.xcodeproj

project
package and uses the target information it finds there to build a product.

To build a target using

xcodebuild

, use the

cd

command
to change to your project’s directory and invoke the

xcodebuild

command with the appropriate options. The project’s directory contains your project’s

.xcodeproj

bundle.
For example, if your project is in

~me/Projects/MyProj

, enter

cd
~me/Projects/MyProj

.

19.Manage targets

When you create a
project from one of the Xcode project templates, Xcode automatically creates a target for you. If, however, your project needs to contain more than one target—usually because you are creating more than one product—you can also add targets to an existing project.If
you are adding targets to your project, chances are you’ve already made a number of decisions about product type, programming language, and framework. Xcode provides a number of target
templates to support your choices. The selection of target templates is similar to the selection of project templates. The target specifies the target’s product type, a list of default build phases, and default definitions for some build settings.
A target template typically includes all build settings and build phases required to build an instance of the specified product. Unlike the project templates provided by Xcode, the target templates do not specify any default files; you must add files to the
target yourself.

To create a target and add it to an existing project:

Choose Project > New Target.

Xcode displays the New Target assistant, which lets you choose from a number of possible target templates. Each target template corresponds to a particular type of product, such as an application or loadable bundle.

Select one of the templates and click Next.

Enter the name of the target.

If more than one project is open, you can choose which project to add the target to from the Add to Project pop-up menu.

Click Finish.

Xcode creates a target configured for the specified product type. Xcode also creates a reference to the target’s product and places it in your project, although the product does not exist on the file system until you build the target.

In addition to some target templates, Xcode defines a handful of target templates that do not necessarily correspond to a particular product type. These targets are known
as special targets and can be used to:

Build a group of targets together

Copy files to a specific file system location

Build a product using an external build system

Run a shell script

These are the special target types:

Aggregate Target

Xcode defines a special type of target that lets you build a group of targets at once, even if those targets do not depend on each other. An aggregate target has no associated product and no build rules. Instead, an aggregate target depends on each of the targets
you want to build together. For example, you may have a group of products that you want to build together. You would create an aggregate target and make it depend on each of the product targets. To build all the products, just build the aggregate target.

An aggregate target may contain a custom Run Script build phase or a Copy Files build phase, but it cannot contain any other build phases. Any build settings that the aggregate target contains are not interpreted but are passed to the build phases that the
target contains.

Copy Files Target

A Copy Files target is an aggregate target that contains only one build phase, a Copy Files build phase. Building a Copy Files target simply copies the associated files to the specified destination in the file system. Copy Files targets are useful if you have
custom build steps that require files that are not specific to any other targets to be copied. While Copy Files build phases allow you to add a step to the build process for a single target that copies files in that target, a Copy Files target lets you copy
files that are not specific to any one target. For example, if your project has several targets that require the same files to be installed at a particular location, you can use a Copy Files target to copy the files, and make each of the other targets depend
upon the Copy Files target.

External Target

Xcode allows you to create targets that do not use the native Xcode build system but instead use an external build tool that you specify. For example, if you have an existing project with a makefile, you can use an external target to run

make

and
build the product.

An external target creates a product but does not contain build phases. Instead, it calls a build tool in a directory. With an external target, you can take full advantage of the Xcode text editor, class browser, and source-level debugger. However, many Xcode
features—such as Fix and Continue—rely on the build information maintained by Xcode for targets using the native build system. As a result, these are not available to an external target. Furthermore, you must maintain your custom build system yourself. For
instance, if you need to add files to an external target built using

make

, you must edit the makefile yourself.

Shell Script Target

A Shell Script target is an aggregate target that contains only one build phase, a Run Script build phase. Building a Shell Script target simply runs the associated shell script. Shell Script targets are useful if you need to perform custom build steps. While
Run Script build phases allow you to add custom steps to the build process for a single target, a Shell Script target lets you define a custom build operation that you can use with many targets. For example, if your project has several targets that use the
files generated by a Shell Script target, you can make each of those targets depend upon the Shell Script target.

There are two main reasons you might need to duplicate a target: You require two targets that are very similar but contain slight differences in the files or build phases
that they include, or you have a complicated set of options that you build with and would prefer to simply start with a copy of a target that already contains those build settings.

Xcode allows you to duplicate a target, creating a copy that contains the same files, build phases, dependencies and build configuration definitions of the original.

To create a copy of a target:

Select the target you want to copy in the Groups & Files list.

Choose one of these:

Edit > Duplicate

Groups & Files list shortcut menu > Duplicate

When your project contains targets that are no longer in use, you may want to remove them to reduce clutter.

To remove a target from a project:

Select the target to delete in the Groups & Files list.

Press the Delete key or choose:

Edit > Delete.

When you delete a target, Xcode also deletes the product reference for the product created by that target and removes any dependencies on the deleted target.

In a complex project, you may have several targets that create a number of related products. Frequently, these targets need to be built in a specific order. Returning to the
example of the client-server software package , you see that the client application, server application, and command-line tool targets each link to the private framework created by another target in the same project.

Before the application and command-line tool targets can be built, the framework target must be built. Because they require the private framework in order to build, each of the application and command-line tool targets is said to depend upon the target that
creates the framework. You can use a target dependency to ensure that Xcode builds targets in the proper order; in this example, you would add a dependency upon the framework target to each of the application and
command-line tool targets.

However, the applications and command-line tool in the client-server package must still be built individually. None of these targets requires the product created by any target other than the framework target. Xcode provides another mechanism for grouping targets
that you want to build together but that are otherwise unrelated; this is an aggregate target . This section shows how to add a target dependency and create an aggregate target, and gives an example of how you
can use these tools to organize a software development effort with multiple products and projects.

Creating Aggregate Targets

To build several targets together, even if they aren’t dependent on each other, create an aggregate target. An aggregate target does not produce a product itself and it does
not contain build rules or information property list entries. Instead it exists so that you can make it dependent on other targets. When you build the aggregate target, the build system builds the targets it depends on sequentially or in parallel. To learn
about building targets concurrently, see "Building in Parallel" .

To create an aggregate target:

Choose Project > New Target.

Select Aggregate from the New Target Assistant.

For each target you want to build with this aggregate target, add a target dependency to the aggregate target.

Adding Target Dependencies

When you build a target (target A) with a dependency upon another target (target B), Xcode makes sure that target B is built and up to date before building target A. That way, you can be sure that when target A needs the product created by target B, target
B is built before target A. In addition, if there are errors building target B, Xcode doesn’t build target A.

You can view and modify a target’s dependencies in two ways:

In the General pane of the target editor. The Direct Dependencies list shows the targets upon which the current target depends.

To add a target dependency, click the plus-sign button. (For the plus sign button to be available, the project must contain or reference more than one target.) The list of targets shown includes all the other targets in the current project, as well as the targets
in any referenced projects. Targets in referenced projects are grouped according to the project to which they belong. You may also drag a target from the Targets group to the Direct Dependencies list.

To remove a target dependency, select it in the list and click the minus button.

In the Groups & Files list. Open the Targets group; the targets that the current target depends on are listed before the build phases in the target. You can make the current target depend on another target by dragging that target to the current target in the
Groups & Files list.

Removing Target Dependencies

To remove a target dependency:

Select the target to modify in the Groups & Files list.

Open the target editor and display the General pane.

In the Direct Dependencies list, select the target dependency to delete.

Click the minus (-) button.

20.Manage target files

When you add files to a project, you can have Xcode also add those files to one or more targets. This is the easiest way to add files to a target. However, you may have existing files in your project that you wish to add to a target, or find that you no longer
need a target file.

Header files have a special purpose in a target: They publish the programming interface to symbols defined or implemented in the target’s implementation files. Implementation files in a target use header files to gain access to symbols defined in other implementation
files. But implementation files may also require access to the programming interface to frameworks, libraries, or plug-ins that are not part of the project.

When you define a target, you may implement symbols you want to make public to clients of the target’s product. But, to make your product easy to use (and to keep implementation details hidden), you may want to keep many of its symbols inaccessible to clients
of your product. Also, if you develop products to be used both by the development team and by end users, you may need to publish interfaces to symbols that must be used only by other team members but that end users must not use. You use a header file’s role within
its target to specify the purpose of the header file.

To set the role of header files in a target:

Select the target containing the header files whose role you want to set.

Select the target’s Copy Headers build phase.

Choose the desired role for each header file from the Role column in the detail view.

There are three roles available:

public

,

private

,
and

project

.

public:The header file is included as part of the build product. Its location is specified by the Public Headers Folder Path (PUBLIC_HEADERS_FOLDER_PATH) build setting. You should publish as

public

only
interfaces that are finalized and meant to be used by your product’s end users.

private:The header file is included as part of the build product. Its location is specified by the Private Headers Folder Path (PRIVATE_HEADERS_FOLDER_PATH) build setting. You should publish as

private

interfaces
that you don’t intend to be used by end users or that are in early stages of development.

project:The header file is available only for use by implementation files in the current project. This header file is not included as part of the built product.

21.Build phases

A build phase represents a task to be performed on a set of files. Each build phase specializes in a specific kind of file, such as header files,
source files, resource files, and frameworks and libraries. Each build phase also performs specific operations on the files associated with it. That way, changes in the way files of the same kind are processed can be made by customizing the operations that
the build phase performs.

As you add files to a project, Xcode associates them with the appropriate build phase, based on
the files’ type (specified by each file’s extension).



Build phases available in Xcode:

Build phase	Description
Copy Headers	Installs header files with public or private roles in the appropriate locations in the product.
Copy Bundle Resources, Build Java Resources	Installs files by copying the associated files from the project to the Resources directory in the product.
Copy Files	Installs files by copying the associated files from the project to a location in the product or to a specific location in the target file system, such as /Library/Frameworks or /Library/Application Support .
Compile Sources	Compiles source files into object files using a predefined tool, a tool you specify, or a build-rule script.
Run Script	Executes a shell script. You can use any scripting language whose scripts you can execute from the command line, such as AppleScript, Perl, Python, Ruby, and so on.
Link Binary With Libraries	Links object files with frameworks and libraries to produce a binary file.
Build ResourceManager Resources	Compiles .r files into resources that go into a separate resource file or into the executable's resource fork.
Compile AppleScripts	Compiles .applescript files and places the resulting .scpt files in the product’s Resources/Scripts directory.

Input files and output files of build phases:

Build phase	Inputs	Outputs
Copy Headers	.h files	Copies in appropriate locations in the product.
Compile Sources	.c , .m , .y , .l , among other types of source files	.o files in target’s build directory.
Link Binary With Libraries	.framework , .dylib , and the .o files in the target’s build directory	Binary file, framework, or library in product destination directory.
Copy Bundle Resources	.nib files, .strings files, image files, and others	Copies in the product’s Resources directory.
Build ResourceManager Resources	.r , and .rsrc files	Resource ( .rsrc ) files in the product’s Resources directory.
Compile AppleScripts	.applescript files	AppleScript script ( .scpt ) files in the product’s Resources/Scripts directory.

Build phases processing order:

The order in which the build system executes build phases is important because some build phases produce files that are part of the inputs of other build phases. Therefore,
the former must be executed before the latter. In native targets, dependencies between build phases determine the order of execution.

In some cases, a build phase inherently includes the outputs of other build phases as its inputs. For
example, the outputs (

.o

files) of the Compile Sources build phase are part of the inputs of the Link Binary With Libraries build phase. This makes the Compile Sources
build phase an antecedent of the Link Binary With Libraries build phase. Therefore, the order in which build phases are executed in a target depends on their inputs and outputs.

Most build phases have their inputs and outputs defined implicitly. However, Run Script build phases
may have neither. Here, the build system tries to run the associated script in the order specified within the target, but the actual point in the build process at which the script is run is undetermined. If you assign either input or output files to a Run
Script build phase, the script’s point of execution in the build process is determined by other targets having the build phase’s outputs as their inputs, or the inputs of the build phase being the outputs of other build phases.For example, regardless
of the order of the Compile Sources and the Link Binary With Libraries build phases in the target, the Compile Sources build phase is executed before the Link Binary With Libraries build phase. This is because the inputs to the Link Binary With Libraries build
phase rely on output from the Compile Sources build phase.In the Compile Sources build phase, the build system determines the order in which files are processed through
the inputs and outputs of the target’s build rules, in a similar way in which the order of build phases is determined.

Typically, there is no need to change the order of build phases in a target; the default arrangement
works for the majority of cases. If, however, you find that you need to change the position of a build phase—for example, when adding custom build phases to a Jam-based target—you can reorder a build phase by dragging the icon for the build phase to its new
location in the target.

Add and delete build phases:

To add a build phase:

(Optional) Select the target to which you want to add the build phase. Otherwise, Xcode adds the build phase to the active target.

Choose a build phase from:

Project > New Build Phase

Xcode adds the new build phase after the currently selected build phase, or, if no build phase is selected, adds it as the last build phase in the target. Several types of build phases can appear only once in a target; for example, there can be only one Compile
Sources build phase. However, a target can contain multiple instances of the Copy Files and Run Script build phases.

To delete a build phase, select it in the Groups & Files list and press Delete, or choose Edit > Delete. Deleting a build phase does not delete the files in the build phase from the project or from the file system.

Add files to a build phase:

When you add a file to a project, Xcode lets you choose whether to also add the file to any targets in the project. When you add files to a target this way, Xcode automatically
assigns the files to build phases, based on each file’s type.

To view the inputs to a particular build phase, you can:

Select the build phase in the Groups & Files list. The files assigned to the build phase are displayed in the detail view.

Open the build phase in the Groups & Files list.

Intermediate files—files generated by Xcode in other build phases—are not listed. Xcode handles these intermediate files automatically.

If the default file placement is not sufficient for your needs, you can drag the file or files from their current build phase to the new build phase. You can also drag existing files from the project group to the appropriate build phase in the Groups & Files
list. To remove a file from a build phase, select the file and press Delete.

Compile sources build phase:

The Compile Sources build phase is one of the most easily customized build phases (the other one being the Run Script build phase). The reason is that this build phase must handle a wide variety of file types. Xcode is preconfigured to process several types
of source files, but you may have to compile source files that Xcode doesn’t know about.

The feature that makes the Compile Sources build phase so flexible is its support of build rules(后面会讲到).

Copy files build phase:

A Copy Files build phase allows you to copy files and resources of any type to specific locations as part of the build process. It complements the build phases that copy specific types of files. An example is the Copy Headers build phase, which deals only with
header files. You can have as many Copy Files build phases as you need in a target.

For example, using a Copy Files build phase, you can copy fonts to

/Library/Fonts

. Or, if you’re developing a plug-in, a Copy Files build phase can copy the generated
plug-in to the appropriate location. You can have as many Copy Files build phases in a target as you need.

To create a Copy Files build phase:

In the project window, open the target to which you want to add the build phase, and select the build phase after which to add the new build phase.

Choose Project > New Build Phase > New Copy Files Build Phase. Xcode adds the new Copy Files build phase after the build phase selected in the Groups & Files list.

Drag the files you want to copy from the Groups & Files list to the Copy Files build phase.

To configure the new Copy Files build phase, select it and open the Copy Files build phase editor.Together,
the Destination pop-up menu and the Path field specify the location to which Xcode copies the files in the Copy Files build phase. The Destination pop-up menu lets you choose from a number of standard locations. Table
below shows the destination-location names you can choose in a Copy Files build phase for an application called MyApp and the resulting destination path. All the options, except Absolute Path and Products Directory, specify paths inside the generated
bundle.

Destination name	Destination path
Absolute Path	Anywhere.
Wrapper	MyApp.app
Executables	MyApp.app/Contents/MacOS
Resources	MyApp.app/Contents/Resources
Java Resources	MyApp.app/Contents/Resources/Java
Frameworks	MyApp.app/Contents/Frameworks
Shared Frameworks	MyApp.app/Contents/SharedFrameworks
Shared Support	MyApp.app/Contents/SharedSupport
Plug-ins	MyApp.app/Contents/PlugIns
Products Directory	The directory in which Xcode places the project’s built products.

The Path field specifies the path, relative to the location specified in the Destination pop-up menu, to the target directory. If you choose Absolute Path from the menu, the
Path field must contain the complete path to the destination directory for the files.

The “Copy only when installing” option lets you specify whether the build phase copies the files only in install builds of the product.

Run script build phase:

Environment variables accessible from a Run Script build phase:





A Run Script build phase lets you execute any commands you need to perform a task. You can archive files using

tar

, send mail, write messages to a log file,
execute AppleScript scripts, and so on. You can use any of the shell languages available in your system. And you can have any number of Run Script build phases in a target.

To create a Run Script build phase:

In the Groups & Files list, open the target to which you want to add the build phase, and select an existing build phase.

Choose Project > New Build Phase > New Shell Script Build Phase.

To configure the new Run Script build phase, open the Run Script build phase Info window.

The Run Script build phase editor contains these fields:

Shell. Specifies the path to the appropriate shell.

Script. Specifies the script itself. You can also enter a script that invokes a script stored elsewhere to, for example, avoid storing an often-changed script in the project file.

A Run Script build phase with the following entries for Shell and Script executes a script called

MyScript.sh

stored in a directory called

Build_Scripts

in
the project directory.

Shell:	/bin/sh
Script:	$(SRCROOT)/Build_Scripts/MyScript.sh

Run script only when installing. Runs the script only during install builds, that is, when using the

install

option
of

xcodebuild

or when the build settings Deployment Location (DEPLOYMENT_LOCATION) and Deployment Postprocessing (DEPLOYMENT_POSTPROCESSING) are on.

Show environment variables in build log. Lists the build system’s environment variables in the build log.

Input Files. Specifies the names of the input files the script operates on.

Output Files. Specifies the files that the script produces.

In these two tables, file paths are interpreted relative to the project directory.

Xcode uses the input and output files to determine whether to run the script and to determine the order in which the script is executed. Specifying input and output files ensures that Xcode runs the script only when the modification date of any of the input
files is later than the modification date of any of the output files (reducing the time it takes to build your product), and that the files the script produces are included in the dependency analysis the build system performs before building your product.
If you provide no outputs, Xcode runs the script every time you build the target.

After the script terminates, Xcode uses the script’s exit value to determine whether to continue the build. When the script exits with a nonzero exit value, Xcode stops the build. If you want to perform other actions—such as writing to a log file—in the event
of a build failure, you must perform the appropriate action in the script.