Creating and Maintaining Projects in Project Builder

This section describes how to create a new project in Project Builder and how to convert a NEXTSTEP project to the Sun^(TM) project format. You will also find information here about maintaining your project.

Creating a New Project

To create a new project, choose the New command in the Project menu. A panel is displayed (see Figure 2-1 on page 2-4) in which you specify a path name and name for the project. Specify a new directory on the Name line, or choose an existing directory in the browser (and leave the name PB.project in the Name field) if you want to use that directory as the root of the new project.

Figure 2-1

By default, the new project is a standalone application. A pop-up list in the panel lets you create a bundle, palette, tool, or library instead. No matter what type of project you create, a project window for the new project is displayed (see Figure 2-2 on page 2-5).

Figure 2-2

You will use this project window to maintain, build, and debug the project, as described in the rest of this chapter. Table 2-2 lists the four modes of operation indicated by the four buttons in the upper right portion of the panel.

Table 2-2

Mode	Purpose
Attributes	Set attributes of your project
Files	Add, remove, or open project files
Finder	Search for text in project files
Builder	Build the project

Opening an Existing Project

To open an existing project, choose the Open command in the Project menu. A standard Open panel is displayed in which you specify the project to open (see Figure 2-3 on page 2-6). Select the file named PB.project in the project directory and click on Open to open the project.

When you open a project, its project window is displayed in Project Manager.

Figure 2-3

Opening and Converting Older Project Types

To open an existing NEXTSTEP project that has not been converted to the Sun project format, choose the Open command in the Project menu. A standard Open panel is displayed in which you specify the project to open. Select the file named PB.project in the project directory and click on Open to open the project.

A panel is displayed warning you that the project file is a NEXTSTEP style project file that needs to be converted to a Sun style project file (see Figure 2-4 on page 2-7). Since the conversion process overwrites several project files, you are asked if you want to back up those files first before converting the project. Unless you are sure you do not need to do this, you should click on Backup First (or Cancel if you decide not to continue)--this causes the PB.project file and its associated makefiles to be saved in a directory named savedNextFiles.

Figure 2-4

Once the project is converted, its project window is displayed in Project Manager. When you save the resulting project, it will be saved as a PB.project file in the same directory. This is the file you will open in the future when you work with the project. You might want to build your newly converted project with the clean target, to make sure that it gets rebuilt from scratch under Sun OpenStep.

The conversion process will convert the existing PB.project and associated makefiles to the OpenStep format. If you have already modified Makefile.preamble or Makefile.postamble, you will have to insert those modifications into the new versions of these files by hand.

Creating a New Subproject

To create a new subproject, open the project in which you want to create it and choose the NewSubproject command in the Project menu. A panel is displayed in which you specify a name and type for the new subproject (see Figure 2-5 on page 2-8). Specify a name for the subproject.

Figure 2-5

A pop-up list in the panel lets you create a bundle or tool that is part of your project instead. No matter what type of subproject you create, the new subproject is displayed in the Subproject category in the project window.

Setting Project Attributes

To bring up the Attributes display shown in Figure 2-6, click on the Attributes button in the project window.

Figure 2-6

The contents of the Attributes display vary depending on the type of project--application, bundle, palette, tool, or library. The contents of these five types of Attributes display are shown in the subsections that follow.

Application Attributes

If the project is an application, the Attributes display contains the controls for defining application attributes shown in Figure 2-7.

Figure 2-7

This group of controls includes fields for specifying the project name, the primary language (that is, the language in which the project is being developed), and the target directory.

The Main File Info, shown in Figure 2-8, has fields for specifying the application class and the application's main nib file, plus an option for regenerating the Main file whenever you save the project. (Project Builder maintains this file and you are not expected to change it; therefore you should leave this option checked, unless there is a reason why you need to maintain the Main file yourself.)

Figure 2-8

The Application Icon well, shown in Figure 2-9, displays the application icon. The default application (shown in Figure 2-9) is used if you do not provide one of your own choosing. To associate a new icon with the application, drag its TIFF file from the workspace into the well. The file is copied to the project directory, although it is not displayed in any of the categories shown in the Files display.

Figure 2-9

The Document Icons and Extensions well, shown in Figure 2-10, is where you indicate what types of documents your application is able to deal with. If you are creating your own document type, create a document icon for it and drag the TIFF file containing that icon into the well. Once the icon is in the well, change its label to match the document extension.

Figure 2-10

The System File Types list, shown in Figure 2-11 on page 2-11, lists OpenStep file types (as identified by their standard OpenStep file extensions), any of which you may choose to have your application handle by selecting the file type in the scrolling list. When you select a file type by clicking on it, a check mark is displayed next to its name, and it is added to the Document Icons and Extensions well. Click on the file type again if you want to deselect it and remove it from the well.

Figure 2-11

Subproject Attributes

If the project is a subproject, the Attributes display contains the controls shown in Figure 2-12 for defining project attributes.

Figure 2-12

The Project Type pop-up list contains items that let you convert the subproject to a bundle or a tool.

The text fields allow you to change the project name and primary language.

Bundle Attributes

If the project is a standalone bundle, the Attributes display contains the controls shown in Figure 2-13 on page 2-12 for defining project attributes.

Figure 2-13

The text fields allow you to change the name, primary language, target directory, and extension.

If the project is a bundle that is part of another project, the Attributes display contains the controls shown in Figure 2-14 for defining project attributes.

Figure 2-14

The Project Type pop-up list contains items that let you convert the bundle to a subproject or a tool. This is possible only with a bundle that is part of another project, not with a standalone bundle.

The text fields allow you to change the project name, primary language, and extension.

Tool Attributes

If the project is a standalone tool, the Attributes display contains the controls shown in Figure 2-15 on page 2-13 for defining project attributes.

Figure 2-15

The text fields allow you to change the name and target directory.

If the project is a tool that is part of another project, the Attributes display contains the controls shown in Figure 2-16 for defining project attributes.

Figure 2-16

The Project Type pop-up list contains items that let you convert the tool to a bundle or a subproject. This is possible only with a tool that is part of another project, not with a standalone tool.

The text field allows you to change the project name.

Palette Attributes

If the project is a palette, the Attributes display contains the controls shown in Figure 2-17 for defining project attributes.

Figure 2-17

The text fields allow you to change the project name and the primary language.

Library Attributes

If the project is a library, the Attributes display contains the controls shown in Figure 2-18 for defining project attributes.

Figure 2-18

The text fields allow you to change the project name, primary language, and target directory.

By default, Project Builder builds Solaris shared libraries for library projects. If you want to build a traditional .a style library archive, you must create your own Makefile.preamble containing the following macro override:

LIBRARY_STYLE = STATIC

See "Creating a Makefile.preamble" on page 2-27 for information on creating your own Makefile.preamble.

Managing Project Files

The Files display of the project window is used to manage the files in the project. You can use this display to add or delete project files, as well as open them for viewing or editing.

To bring up the Files display, shown in Figure 2-19 on page 2-15, click on the Files button in the project window.

Figure 2-19

The Files display provides a file viewer similar to the Workspace Manager's File Viewer, with categories of project components displayed in the left-hand column and project files for each category displayed to the right. These project categories do not correspond to project subdirectories--the categories are logical rather than physical groupings of files.

The project directory provides you and Project Builder with a convenient way to organize the files used in putting together your application. As shown here, files in the project directory are grouped by Project Builder into a number of categories. These categories are represented with a suitcase icon (and are frequently referred to as suitcases). These categories are described briefly in Table 2-3 on page 2-16.

Table 2-3

Category	Description
Classes	Files containing code for custom classes used by an application.
Headers	Files containing declarations of methods and functions used by an application.
Other Sources	Files containing code (other than class code) for an application. These may include.m files (containing Objective C code), .c files (containing standard C code), .C or .cc files (containing C++ code), .psw files (containing PostScript(TM) code), and other sources. Project Builder automatically adds the file ApplicationName_main.m to Other Sources.
Interfaces	Nib files for each application and for each new module added to an application. The flag icon next to a file name in the Interfaces suitcase indicates that the file is localizable (that is, the file is in the Language.lproj subdirectory in the project directory, rather than in the project directory itself).
Images	Files containing images (other than icons) used by an application, including TIFF or EPS files.
Other Resources	Files (such as sound files) for other resources used by an application.
Subprojects	Directories containing subprojects used by an application.
Supporting Files	Files not used directly by the application but that should be kept with the application.
Libraries	Libraries referenced by an application. OpenStep libraries are referenced but not copied into the project directory. Other libraries, such as those you create, may be added to the project directory.

You can use Project Builder's file viewer to do the following:

• Browse the project and the files it contains.
• Add files to the project (as described in "Adding Files to a Project" on page 2-17).
• Remove files from the project by selecting the file in the browser and then choosing Remove in the Files menu.

• Open a project file by double-clicking on its name or icon (or, by selecting the file in the browser and then choosing Open in Workspace in the Files menu).

Adding Files to a Project

There are several ways to add an existing file to a project. The file can be already located in the project directory, or it can be somewhere else. To add it, use one of the following methods:

• Drag the file from the File Viewer into the project window. If you drag it to the suitcase in which it belongs, that suitcase opens up. If you let it go, it is added to that suitcase. If instead you drag it to the project suitcase, the project suitcase opens up and the file is added to it. The Classes suitcase takes .m files, the Headers takes .h files, and so on. Other Sources refers to files that are not headers or classes, but need to be compiled and linked into the target of the project (application, bundle or palette). Other Resources refers to files that need to be copied into the target. Supporting Files refers to files that are necessary to maintain the project, but do not become part of the target.
• Select a suitcase and choose the Add command in the Files menu (or simply double-click the suitcase). A panel is displayed in which you specify a file to add to the selected suitcase.
• Use the service that Project Builder supplies to other applications. Relevant applications have a command named Project in their Services menu. This command displays a submenu containing two commands: Add To and Build. Add To can be used to add the current file to the project (in this case, the file must already be located in the project directory).

File Display Shortcuts

The following shortcuts are available in the File display:

• Control-dragging in a file list allows you to reorder the files. This can be especially important in dealing with libraries, since the file order determines the link order.
• Alt-double-clicking on the icon of a selected file selects that file in the workspace File Viewer, instead of opening it.

• Command-double-clicking on a source file opens both the file and its associated header file, if it exists.

Building the Project

When you instruct Project Builder to build the project, the project is compiled by the make utility using the project's makefile. The project's source files are compiled and linked into an executable file. The project makefile provides the information the make utility needs to do this job. The warnings generated by the compiler and link editor provide information to help you locate and fix bugs detected at compile time.

---

Note - You can specify default build arguments, which apply for all projects, with the Preferences command in the Info menu. See "Setting Preferences" on page 2-29 for information on Project Builder's Preferences panel.

---

To build the project, first bring up the Builder display, shown in Figure 2-20, by clicking on the Builder button in the project window.

Figure 2-20

The Target pop-up list, shown in Figure 2-21 on page 2-19, lets you specify a build target for the project. The build targets on the pop-up list are described in Table 2-5 on page 2-23.

You can add a custom target to the pop-up list using the Add option at the botton of the list. When you add a custom target, it is displayed as an option in the pop-up list for the current project only.

The default build target is "app" for application projects, "bundle" for bundle projects, "palette" for palette projects, or "tool" for tool projects. You can choose another target for this project.

Figure 2-21

The Options button, shown in Figure 2-22, brings up the Build Options panel (see Figure 2-23) in which you can specify the build options described in Table 2-4.

Figure 2-22

If you want to specify the build attributes using the Build Options panel, be sure to do so before starting to build the project.

Table 2-4

Option	Description
Arguments	Arguments to be passed on the command line to the make utility that is run during the build.
Host	The host on which the project will be built. The remote host you choose must have network access to your project directory. If you specify a host here, it overrides any host specified in the Preferences panel.
Build after error	Lets you override the Preferences setting of the option to continue building projects even when a fatal error is encountered during compiling.
Compiler	Extra command line arguments to be passed to the compiler
Linker	Extra command line arguments to be passed to the linker
Library search order	A list of directories in which the linker will search for libraries
Header file search order	A list of directories in which the compiler will search for header files

Figure 2-23

---

Note - If you build the project on a remote host, be sure you know what version of OpenStep the host is running.

---

When you are ready to build the project, click on the Build button (shown in Figure 2-24 on page 2-22).

Figure 2-24

As the build progresses, the two views at the bottom of the window (see Figure 2-25) inform you of any warnings or error messages that occur--the upper Summary view is more selective in what it chooses to display, so you may choose to hide the lower Detail view and only refer to its output when you need to.

Figure 2-25

If an error is encountered during the build process, a message is displayed in both the Summary view and the Detail view.

Click on a line in the Summary view to open the specified file; if you click on a line containing an error message (shown in red), the file opens in Edit and scrolls to display the line that contains the error.

Build Targets

The shared Makefile used to generate the executable file for all applications created with Project Builder, app.make, defines a number of alternate targets to perform specific tasks at various phases of the application development process. To run the make utility using the alternate targets, select the corresponding argument from the Targets pop-up list in the Builder display (see Figure 2-21 on page 2-19).The pop-up list provides various targets, which are listed in Table 2-5 along with the tasks they perform.

Table 2-5

1 Target	Task
app/bundle/palette	Compiles and links an optimized version of the project. The target in this first pop-up item can be app, bundle, or palette, depending on the type of project you are building. The default target produces the same result.
clean	Removes all derived files, such as object and executable files, from the project directory, returning the project to its precompiled state.
debug	Compiles (with all warnings and -DDEBUG on) and links a debuggable, unoptimized version of the executable file with the extension .debug.
profile	Generates (with all warnings and -DPROFILE on) the file ApplicationName.profile, an executable containing code to generate a gprof report. This option is useful when you are performance tuning an application. See the UNIX(R) manual page gprof for details on profiling.
install	Compiles and links an optimized version of the project. Then copies the application into the installation directory specified in Project Builder, setting permissions and owners as appropriate, and strips the installed project. The default installation directory is $(HOME)/openstep/Apps, the Apps directory in the user's home directory.
default	Compiles and links the project in the same way as the first entry in the pop-up list (app, bundle, or palette).

1. Project Builder does not support a "depend" build target. Instead, it uses the Solaris make utility's .KEEP_STATE mechanism (see the UNIX manual page for the make utility). The presence of a target name .KEEP_STATE in a makefile causes the make utility and the compiler to record dependencies in a file called .make.state. These dependencies are used in future builds to determine which targets are out of date.

The Preamble and Postamble Files

Every make command run by Project Builder includes a file named Makefile.preamble that contains definitions of all the user-configurable macros that are used in the rest of the Project Builder Makefiles. By default, this file is /usr/openstep/Developer/Makefiles/Makefile.preamble.

If you need to customize the make process for a project, you can create a local version of Makefile.preamble in the top directory of the project. The file's presence causes it to be included by the project makefiles instead of the standard /usr/openstep/Developer/Makefiles/Makefile.preamble.

If you need to customize the make process for a project that includes IDL interface files, see "Defining User-configurable Macros for a Project with IDL Interfaces" on page 2-27.

Your local Makefile.preamble should contain the following:

include $(OSHOME)/Developer/Makefile/Makefile.preamble
<your customizations>

The include causes the standard Makefile.preamble to be included. Then <your customizations> can override or add to any of the macros defined therein.

For example, the standard Makefile.preamble defines the optimization compiler option as follows:

OPTIMIZATION_CFLAG = -O

To change this to -O2, your local Makefile.preamble would contain the following:

include $(OSHOME)/Developer/Makefile/Makefile.preamble)
OPTIMIZATION_CFLAG = -O2

A Makefile.preamble in the top level directory of a project is included by make commands in all the directories of the project, so a customization contained therein occurs in the make command in each project directory.

You can also create a customization that applies only to a single directory of a project. To do so, create a file named Makefile.postamble in that directory. The presence of this file causes it to be included in the make command for that directory only.

A Makefile.postamble can add to or redefine any of the macros defined in /usr/openstep/Developer/Makefiles/Makefile.preamble. It can also define additional targets, or additions to existing targets through the :: make construct.

You can also build a project by entering make commands into a shell command line. You can specify any of the targets shown in Table 2-5 on page 2-23. For example:

make app install

builds an optimized version of the application and then installs it.

You can specify to the make utility, or add to the Build Targets pop-up list, the additional targets listed in Table 2-6 on page 2-26.

Table 2-6

Target	Task
strip	Strips the optimized version by removing relocation information.
1 quick	Runs a make debug command,but not a make command in a subdirectory unless a file in that subdirectory has been modified since the last time it was built. Use this target when you have built the project and then modified some .m files.
1 link	Runs the make utility on only the top level directory of a project, causing modified files to be compiled and the final link to be performed.
1 <subdir>	If a project contains multiple directories, you can run the make utility only in the top level directory. However, from the top level, you can run the make utility in individual second level directories by specifying directory names as targets on the make command. For example, if project gus contains subproject fred.subproj and bundle sam.bproj, then if you modify a file in the bundle, you can quickly rebuild the project as follows: :make sam.bproj This runs the make utility in the bundle but will not rebuild the top level directory or the subproject. If you modify a file in the subproject, then you could use the following: make fred.subproj link The link target is necessary since the result of runnng the make utility in a subproject is a .o file that must be linked into the top-level executable. The link target is not necessary on the make sam.bproj command since bundles are dynamically loaded and do not have to be linked into the top-level executable.

1. These targets are intended to speed up the execution of make commands during the debugging process. Each will run a debug mode make command in portions of a multi-directory project. You should use these targets only when you are sure that the partial updates that result will suffice.

Defining User-configurable Macros for a Project with IDL Interfaces

If you have included IDL interface files in your project using Interface Builder (as described in "Adding IDL Template Objects to Your Interface" on page 3-164), you must create a local version of Makefile.preamble in the top directory of the project as described in "Creating a Makefile.preamble" , or perform the steps described in "Using Project Builder to Define User-configurable Macros" on page 2-28.

Creating a Makefile.preamble The Makefile.preamble file for a project that includes IDL interface files must contain the following:

• Modifications to the COMMON_CFLAGS macro to set include file paths for the header files generated from IDL interface files included using Interface Builder, if the headers are in different directories than the IDL interface files. If the headers are in the same directories, then Project Builder sets up the paths.
• Modifications to the OTHER_LDFLAGS macro to include paths and shared libraries for the IDL stub libraries generated from the IDL interface files.
• Modifications to the OTHER_LDFLAGS macro for the path and name of the ODF library.

If the server with which you intend to connect is running in development mode, you also need to modify OTHER_LDFLAGS to include an additional relocatable, /opt/SUNWdoe/lib/odf/development_mode.o. This is required for successful name service lookup on NEO servers running in development mode.

To find out if the server is running under the development mode start neoadmin from a shell command line. In neoadmin, type the server command to view the NEO servers. If the service of interest has a .development extension, it is running in development mode. For more information on how to use neoadmin, see .

The following is a sample Makefile.preamble:

------------------------------------------------------------------
include $(PREAMBLE)
COMMON_CFLAGS =-I/opt/SUNWdoe/include \
        -I<include path>/odf_output
OTHER_LDFLAGS =-L/opt/SUNWdoe/lib \
             -R/opt/SUNWdoe/lib \
             -L<library path> \
             -R<library path> \
             -lOdf -l<stub library>
OTHER_OFILES += /opt/SUNWdoe/lib/odf/development_mode.o
------------------------------------------------------------------

Using Project Builder to Define User-configurable Macros Instead of creating a Makefile.preamble, you can define the user-configurable macros for a project that includes IDL interface files by using the project window and performing the following steps:

1. Click on the Builder button in the Project Window to bring up the Builder display. Click on the Options buttonto open the Options panel.

2. Add the -I options to the Header Search Order list, and add the -L/-R options to the Library Search Order list.

3. Click on the Files button in the Project Window to bring up the Files display.

4. Drag the Odf library name and the <stub library> name from the FileViewer to the Libraries suitcase in the Files display.

5. Drag the development_mode.o file from the File Viewer to the Other Sources suitcase. Unfortunately, this will make a copy of it. If you do not want a copy, then before dragging the file, use an ln -s command to link this .o file into the top directory of the project. When you drag the file to the Other Sources suitcase, an attention panel will tell you the file already exists and ask if you want to replace it. Reply No.

Setting Preferences

You can specify preferences for a variety of options using the Preferences panel. To bring up the panel, choose the Preferences command in the Info menu.

Enter values or click on buttons to specify new preferences. Then click on Set to set the new preferences (or click on Revert to restore the previous settings).

---

Note - The settings on the Preferences panel are global--they apply to all projects, not just the current project. The settings can be overridden for a specific project by settings you specify in the Build Options panel for that project (see Figure 2-23 on page 2-21).

---

Build Defaults Controls

The controls in the Build Defaults group, shown in Figure 2-26, let you specify alternate targets to display in the Builder display's Targets pop-up list (see Figure 2-21 on page 2-19). They also let you specify build arguments to be passed to the make utility and a remote host on which to build the project. The switch lets you choose to continue building a project even when a fatal error is encountered during compiling.

Figure 2-26

Tools Controls

The controls in the Tools group, shown in Figure 2-27 on page 2-30, let you specify the programs to use to edit source code and debug the executable--these files are used in interactive debugging with Project Builder. You can also specify an alternative to /bin/make, the standard make utility.

Figure 2-27

The default editor that Project Builder uses to display files is the OpenStep Edit application. However, you can configure Project Builder to use a different editor by entering a command to invoke that editor in the Editor field of the Preferences panel. If the Editor field does not contain a command that invokes an OpenStep application, then Project Builder does the following when it opens a file in the specified editor:

• If the command in the field is vi, Project Builder runs the following command:

/usr/openwin/bin/xterm -e vi +<lineNum> <fileName>

• If the command begins with xemacs, Project Builder runs the following command:

gnuclient -q +<lineNum> <fileName>

In order for this command to work, the following conditions must exist:

• The gnuclient application must be found in a directory in your search path. It is normally in same directory as the xemacs executable file.
• You must already have the xemacs application running and you must have run the xemacs command M-x gnuserver-start. This command starts a daemon that is a go-between between the xemacs and gnuclient applications.

• If the Editor field contains any command other than vi or xemacs, Project Builder runs the following

<command> +<lineNum> <fileName>

For example, if you want to use shellTool instead of xterm to run the vi application, the command could be the following:

/usr/openwin/bin/shelltool vi

Sounds Controls

The controls in the Sounds group, shown in Figure 2-28, let you specify the sound cues for Project Builder to use when the project builds successfully, and when the project fails to build.

Figure 2-28

Build Service Controls

The controls in the Build Service group, shown in Figure 2-29, let you specify what (if anything) you want to have happen after building your project (specifically, after building your project by choosing Project Builder's Build command on the Services menu)--Build only, Build and Run, or Build and Debug.

Figure 2-29

Save Options Controls

The controls in the Save Options group, shown in Figure 2-30, let you specify whether projects should be autosaved, and whether the most recent backup file is automatically deleted or retained.

Figure 2-30

Running and Debugging an Application

In addition to maintaining and building a project, you can use Project Builder to run or debug the resulting application, as described in the following sections.

Running

To run the project application, click on the Run button in the project window, shown in Figure 2-31. If the project has not been built yet, it is built and then the application is run. The Run button's icon is the same as the application icon--the icon shown here is the default application icon that Project Builder uses if no other icon is specified in the Attributes display.

Alt-clicking on the Run button runs the application without building it first.

Figure 2-31

Debugging

To debug the project application, click on the Debug button in the project window, shown in Figure 2-32. If the project has not been built yet, it is built first and then the application is run in debug mode.

Alt-clicking on the Debug button runs the application under the SPARCworks Debugger without building it first.

Figure 2-32

When you indicate that you want to debug an application in Project Builder, the following steps occur:

• The project is built (unless it is already up to date).
• Terminal creates a new window in which to run the Debugger process.

For information about using the SPARCworks Debugger, see the SPARCworks manual Debugging a Program.

Project Builder Command Reference

Project Builder's main menu contains the standard Info, Edit, Windows, Services, Hide, and Quit commands. All commands unique to Project Builder are located in the Project and Files submenus--these menus and the commands they contain are described below.

Commands in the Project Menu

The Project menu contains commands for creating and maintaining your projects, as listed in Table 2-7.

Table 2-7

Command	Description
New	Creates a new project.
Open	Opens an existing project.
Open Makefile	Opens a window for just the Makefile of a project and displays the Builder view in the window. To build the project, click on the Build button.
Save	Saves the current project.
New Subproject	Creates a new subproject
Add Help Directory	Adds a Help directory to the current project. A template Table of Contents file and Index file are placed in the Help directory. For more information on adding help to an application, see "Attaching Help to Objects" on page 3-132 and "Adding Help Links" on page 4-17.

Table 2-7 (Continued)

Command	Description
Run Application	Runs the application associated with the project, just as if you had clicked on the Run button in the project window.
Debug Application	Debugs the application associated with the project, just as if you had clicked on the Debug button in the project window.
Build Application	Builds the application associated with the project, just as if you had clicked on the Build button in the project window.

Commands in the Files Menu

The Files menu contains commands, shown in Table 2-8, that affect the files that make up a particular project. Commands in this menu are enabled only when the Files view for the project is selected.

Table 2-8

Command	Description
Add	Adds a file to the selected suitcase in the current project. Be sure to select the appropriate suitcase in the Files display before choosing the command.
Open in Workspace	Opens the selected file in the application that is registered with the Workspace Manager as the default application for files of that type.
Select in Workspace	Displays and highlights the selected file in the Workspace Manager's File Viewer window.
Remove	Removes the selected file from the current project (without deleting it from the project directory).
Sort	Alphabetically sorts the files in the current suitcase.
Make Global	Makes the selected file global (that is, moves it from the Language.lproj directory into the project directory).

Table 2-8 (Continued)

Command	Description
Make Localizable	Makes the selected file localizable (that is, moves it from the project directory into the Language.lproj directory).
Make Public	Makes the selected header file public. The file is flagged in the File view in the Project window. Public files are also flagged in the PB.Project directory and the makefile so that they are installed in a target directory where they can be accessed by others when the header files are installed by the Make utility.
Make Private	Makes the selected public header files private; that is, reverses the effects of Make Public.