1. Trang chủ
  2. » Công Nghệ Thông Tin

Lập trình Wrox Professional Xcode 3 cho Mac OS part 47 pps

7 207 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 7
Dung lượng 2,77 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Copy Files An Aggregate target with a single Copy Files build phase.. Targets typically have one Compile Sources build phase that compiles all of the source fi les for that target, even

Trang 1

TARGET DESCRIPTION

Aggregate An empty Aggregate target

Copy Files An Aggregate target with a single Copy Files build phase

External A Jam - based External target External targets run some external process

(like make) to build the target They cannot have build phases

Shell Script An Aggregate target with a single Run Script build phase

Legacy

If you upgraded an earlier version of Xcode, your installation may contain additional target templates that have since been removed from the Xcode Developer Tools These might include Java Applet, Carbon, and other deprecated targets For the most part, Xcode still supports these legacy target templates, but may not in the future

Duplicating Targets

You can also create a new target by duplicating an existing one This is especially useful if you need

a new target that is very similar to one that already exists Select the target in the Targets smart group In the Right/Control+click contextual menu choose the Duplicate command A duplicate

of the target is created with the suffi x “ copy ” appended to the target ’ s name Note that the new target is an exact duplicate except, of course, for its name If the original target produced a product, the new target will produce the same product Assuming you want the targets to build separate products, remember to edit the settings of the target so the two products don ’ t overwrite one another

Deleting Targets

To delete a target, select the target in the Targets smart group Press the Delete key or choose Delete from the Right/Control+click contextual menu Xcode presents a warning that removing a target will also remove the reference to it in any targets that depend on it Click the Delete button to acknowledge the warning and delete the target

BUILD PHASES

Build phases defi ne the steps that must occur in order to build a target Build phases tend to paint

with a broad brush Targets typically have one Compile Sources build phase that compiles all of

the source fi les for that target, even if that includes source fi les from many different languages

Consequently, targets rarely have more than three or four build phases

Use the disclosure triangle next to the target ’ s name in the Targets smart group to reveal the build phases for the target, as shown in Figure 16 - 9 The list of fi les on which a build phase will operate, or depends, is referred to as the phase ’ s input fi les Selecting a build phase lists the input

Download at getcoolebook.com

Trang 2

fi les in the details pane of the project window Alternatively, you can use the disclosure triangle

on a build phase to list the input fi les in the Groups & Files list The number of input fi les is listed

in parentheses after the name of the build phase Note that this applies only to build phases that

process fi les using Xcode ’ s internal build system The input fi les listed for a build phase include only

those source fi les that you have explicitly added to the build phase Intermediate fi les produced by

another build phase are not listed or counted

FIGURE 16 - 9

Build phases occur in the order in which they appear in the target Build phases can be reordered

by dragging a build phase to a new position in the target Be very careful when doing this The

reason build phases exist is because build steps have to occur in a specifi c order for the build to

be successful — you can ’ t link code before it ’ s compiled About the only time you ’ ll fi nd yourself

reordering build phases is if you add your own build phase and need that phase to occur before

or after another phase You can also reorder the fi les that a build phase includes For some build

phases, this may be a signifi cant change For others, the order of fi les is superfl uous You cannot

drag build phases into other targets, nor can you copy them via the clipboard

New build phases are simple to add Select a target and choose a new build phase from the

Project ➪ New Build Phase menu or Right/Control+click an existing target or build phase, and

choose an item from the Add ➪ New Build Phase menu Not all build phase types can be added to

all target types An aggregate target can only contain Copy Files and Run Script build phases An

external target cannot have any build phases The New Build Phase menu lists only those phases

appropriate to the selected target After you ’ ve added the build phase, drag it to set its order in the

target and then confi gure the new phase as desired

To remove a build phase, select it and press the Delete key or choose Delete from the Right/

Control+click contextual menu

Files in a Build Phase

Every build phase has a set of preferred source fi le types A Compile Sources phase prefers the source

fi le types it has build rules for ( .c , .cpp , .m , .l , and so on) — build rules are described later in the

“ Build Rules ” section The Copy Bundle Resources phase prefers the resource fi les one typically

Download at getcoolebook.com

Trang 3

copies into an application ’ s bundle ( .tiff , .icn , .png , and so on) When you add a source fi le to a target, the fi le becomes an input fi le for the fi rst phase that prefers that fi le type the most If a target contains both a Copy Headers phase and a Copy Files phase, adding an .h fi le to that target adds the fi le to the Copy Headers phase The Copy Headers phase is more specifi c than the Copy Files phase, and prefers .h fi les more than the Copy Files phase does If a target contains only two Copy Headers phases, adding an .h fi le adds it to the fi rst Copy Headers phase in the target, because both phases prefer an .h fi le equally

Adding Items to Targets

You typically add fi les to targets via the targets list that appears when the fi le is created, added to the project, in the Info window for the fi le, or using the target check box column in the project window This is usually foolproof and effective, allowing Xcode to choose automatically the appropriate phase to add the fi le to If a target has no phases that prefer a source fi le ’ s type, that fi le cannot be added to that target using any of the aforementioned dialogs

Precisely Controlling Target Phase Membership

Using the target group, you have more precise control over what input fi les are included in what phases, and you can occasionally break the rules You can add a source fi le

to a build phase by dragging the fi le into that phase and dropping it Figure 16 - 10 shows the Image1.png fi le being added to the Copy Bundle Resources phase

You can move or copy a fi le from one phase to another In the previous example, where there was both a Copy Files and a Copy Headers phase, you may really have wanted a specifi c header fi le to be in the Copy Files phase, not the Copy Headers phase Just adding the fi le to the target puts

it in the Copy Headers phase Grab the fi le in the Copy Headers phase and move it into the Copy Files phase

Hold down the Option key before dropping it, and Xcode duplicates the reference, adding the fi le to both phases

Using drag and drop, you can include a fi le in more than one phase and you can include the fi le

in phases that don ’ t prefer it Let ’ s say you have developed a Java application that dynamically produces executable Java code by manipulating a source fi le template and then compiling it You want the Java source template fi le, GenericTransformTemplate.java , to be included in the application ’ s bundle as a resource fi le To accomplish this, drag the GenericTransformTemplate java fi le into the Copy Bundle Resources phase When the application is built, this Java source

fi le is copied into the resource bundle of the fi nished application, something that would normally never happen

Removing an Item from a Target

You can remove a source fi le from a target by selecting it and pressing the Delete key or choosing Delete from the Right/Control+click contextual menu You will receive a warning from Xcode

FIGURE 16 - 10

Download at getcoolebook.com

Trang 4

asking if you want to delete the item Don ’ t panic You are only deleting the phase ’ s reference to the

source fi le, not the source fi le itself

If you have added a source fi le to any phase of a target, Xcode indicates that it is a member of

that target Removing (unchecking) a target in a target list removes that fi le from every phase it is

included in

It’s possible to create a paradox if you have manually forced a source fi le to be included in a target that has no phases that prefer that fi le type; the target for that source fi le will indicate that it is a member, but the check box control for the target will be disabled (because there are no phases that prefer that type) To remove a fi le from a target under these circumstances, you must delete the fi le directly from the build phase or phases

Build Phase Types

There are nine build phase types: Compile Sources, Compile AppleScripts, Link Binary With

Libraries, Copy Headers, Copy Bundle Resources, Copy Files, Build Java Resources, Build

ResourceManager Resources, and Run Script

Compiler Phases

The Compile Sources phase is the most sophisticated of the build phases It is responsible for

compiling any kind of source fi le The kinds of sources fi les it will compile and what compiler it will

use for each are determined by the build rules for the target, described later in the “ Build Rules ”

section The Compile Source phase understands a vast array of build settings that apply to the

compilers It parses all of these and makes the appropriate adjustments to the parameters passed to

each compiler

The Compile AppleScripts phase is similar to Compile Sources, but it only compiles AppleScript

source fi les The Build ResourceManager Resources phase is another specialized compiler phase just

for resource defi nitions fi les It compiles and merges legacy .r and .rsrc fi les to produce a resource

fi le in the product ’ s bundle, or inserts them into the resource fork of the product fi le You ’ re not

likely to run across any ResourceManager Resource phases unless you ’ re working on older

Carbon projects

The Link Binary With Libraries phase is the companion to the Compile Sources phase It takes

whatever intermediate fi les were produced by the Compile Sources phase and links them together,

along with whatever libraries and frameworks they need The input fi les to the link phase are the

external libraries and frameworks that the object fi les (from the previous phase) need to be linked to

Copy Phases

The Copy Headers, Copy Bundle Resources, and (legacy) Build Java Resources phases are

specialized versions of the Copy Files phase Their sole purpose is to copy fi les into the

product ’ s bundle

Download at getcoolebook.com

Trang 5

Copy Headers is designed for use with framework and library targets It uses the “ role ” of its input

fi les, be they public or private, and copies them to the appropriate location in the output project

The role of a header is set using the role column of the details pane with that fi le or phase selected

Copy Bundle Resources copies any input fi le into the Resources folder of the product ’ s bundle

This is the phase to use if you want a literal copy of a fi le stored in your bundle ’ s resource folder for access at run time This phase is also responsible for constructing and copying the Info.plist fi le into the product ’ s bundle (See the “ Properties ” section later in this chapter for more about how to confi gure the Info.plist fi le.)

The Copy Files phase is a utilitarian phase that copies all

of the phase ’ s input fi les or folders to the destination of your choice That destination is set in the Info window

of the phase, as shown in Figure 16 - 11 The destination location can be either an absolute path or a path relative

to the product ’ s location For targets that produce a bundle, predefi ned locations are provided that will target many of the standard locations in the product ’ s bundle

An absolute path is just that Use this to copy fi les to a particular installation or test location

Relative paths require a bit of an explanation The build location — the location to which the product of a target will be written — is unique for each build confi guration If you have two build confi gurations, Debug and Release, every target will produce two different products: a Debug product and a Release product The remaining paths in the destination menu are all relative to the product ’ s output directory The choices are the output directory itself or one of the standard folders inside a bundle, assuming the target produces a bundle (See Chapter 17 for a complete explanation

of build locations and build confi gurations.) The path fi eld can be left blank for any choice other than Absolute Any folders that do not exist when the phase executes are automatically created

The path can also contain build variables using the form $(BUILD_VAR) The macro will be substituted for its actual value when the build phase runs By using build variables in the path, you can customize the normal destination location calculated by Xcode

Speaking of build locations, remember when Chapter 5 mentioned that product-relative references are based on the active build confi guration and target? This fact is most applicable to product fi le references used as input fi les to a Copy Files phase Product references also change based on the active build confi guration, making both the source and destination locations of the phase variable An example would be an application that includes a BSD executable in its bundle

A Copy Files phase could be used to copy the project-relative product produced

by the BSD target into the resource bundle being produced by the application target Both the source (product reference) and the destination (application bundle) are variable When built using the Debug build confi guration, the Debug version of the BSD product is copied into the Debug version of the application bundle When the Release confi guration is active, the Release version of the BSD product is copied into the Release version of the application bundle

FIGURE 16 - 11

Download at getcoolebook.com

Trang 6

If the Copy Only When Installing option is set, the copy phase is only executed when the build is

being performed with the install option set You can do this from within Xcode by turning on the

DEPLOYMENT_LOCATION build setting or passing the install option to the xcodebuild tool Both of

these are described in Chapter 17

Script Phase

The Run Script phase is the “ backdoor ” by

which you can interject virtually any custom

build procedure You confi gure a Run Script

phase using the Info window of the phase,

as shown in Figure 16 - 12 The Shell fi eld

determines the shell, or interpreter, that will

be used to execute the script Below that is the

shell script that will be executed

When the phase is built, the shell executable

is put on a so - called “ she - bang ” line

( #! /path/to/shell ) and the remaining

script is appended to it The whole thing is

written into an executable script fi le and run

using the sh tool One side effect is that the

zeroth argument to the script will be the path

to the temporary script itself, which makes it

relatively uninformative

The Shell fi eld can be any valid interpreter

It could be perl, ruby, awk, or php It doesn ’ t

matter, as long as the given interpreter can

execute the script fi le Most of the build settings are transferred into environment variables before

the script is executed, so your script has unfettered access to your build settings

If you ’ re interested, or are having trouble with the build settings passed to your script, check the

Show Environment Variables In Build Log option This option dumps the entire shell environment

prior to execution into the build log for later analysis

Checking the Run Script Only When Installing option prohibits the script from running unless

the DEPLOYMENT_LOCATION build setting is turned on or the install command is passed to the

xcodebuild tool

Xcode, of course, has no idea what your script will do, what fi les it needs, or what it produces

Assuming that the script produces some output fi les from some input fi les, Xcode would like to

optimize the build by skipping this build phase if the modifi cation dates of the output fi les are

newer than the input fi les You can satisfy Xcode ’ s curiosity by manually setting the Input Files and

Output Files for the phase Click the + button to add an input or output fi le to the list When the

new entry appears, enter the fi le ’ s path Sadly, you can ’ t drag a source fi le from the project window

into the list However, once an entry is created you can drag a source fi le into the fi eld and then edit

the path It can be an absolute path or a path relative to the project directory The script is run only

if the modifi cation date of one or more of the input fi les is more recent than the oldest output fi le If

either list is empty, the script runs every time

FIGURE 16 - 12

Download at getcoolebook.com

Trang 7

The fi les in the Input Files list are not passed to the script as parameters, nor are they piped to it via stdin They are used by Xcode solely to determine if the script should be run It is up to the shell script to read the listed Input Files and produce all of the fi les promised in the Output Files If you want to reuse a script

in multiple targets and need a variable list of input or output fi les, defi ne them in

a custom build setting.

BUILD RULES

Build rules defi ne the transformation of source fi les into their compiled results The compiler phase uses the target ’ s build rules to determine which compiler should be used to compile each source

fi le For example, a build rule might specify that all C source fi les (C, C++, and Objective - C) are compiled using the gcc compiler

A build rule applies to all the fi les of a specifi c type The type of a fi le is determined by its extension

or the fi le type assigned to that source fi le A fi le ’ s type is typically in agreement with the fi lename

extensions, but it doesn ’ t have to be You can change the fi le type of a .java source fi le to

sourcecode.cpp The Compile Sources phase will then apply the sourcecode.cpp rule to that fi le

as if it were a C++ source fi le — probably without much success

You ’ ll probably never need to alter the build rules in Xcode However, there are several reasons why you might want to:

Force Xcode to use an older, newer, or custom compiler

Add a rule to compile a source type that is not normally compiled by Xcode

Add a pre - or post - processing script to every compilation

Defi ne your own transformation

You can examine and alter the build rules, previously shown in Figure 16 - 4, for a target in the target ’ s Info window When it comes time to compile an input fi le, the fi le is tested against each rule starting from the top of the list The fi rst rule that matches a particular input fi le is the rule used to compile that fi le

Each target has one set of build rules, shared by all of the build phases in that target You cannot create different rules for different phases of the same target

Every set of build rules includes a set of system rules that cannot be edited The system rules are always at the bottom of the list You can add your own custom rules to a target These custom rules can only be added to the top of the list and are always evaluated before any of the system rules

If you defi ne a rule that matches the same type of fi le as a system rule, your custom rule is used instead Click and drag the title of a custom rule to reorder it in the list

Download at getcoolebook.com

Ngày đăng: 04/07/2014, 06:20