A Taste of Project Builder
Volume Number: 19 (2003)
Issue Number: 1
Column Tag: Getting Started
A Taste of Project Builder
by Dave Mark
As promised in last month's column, this month we're going to take a walk through the Project Builder debugger. Before we do, I want to touch on an issue that has been raised by a number of readers, especially folks who work in both CodeWarrior and Project Builder.
Where the Heck is the Standard Library?
CodeWarrior and Project Builder each have their own distinctive look and feel, especially when it comes to the Project Window. One point of confusion concerns the location of the Standard Library. In CodeWarrior, the Standard Library is (typically) explicitly included in the project. Sometimes this is done by creating a project from a Metrowerks Standard Library (MSL) template. Other times, you add the MSL library to your project yourself, choosing from a selection of precompiled versions of the MSL, or perhaps custom compiling your own version.
Bottom line, when you look at your Project Window, you know you've got MSL in your project because it is listed in the window along with all your other source code, libraries, etc. Want to get rid of the MSL? Select it and hit the delete key.
Project Builder follows a different tack. In the Project Builder Project Window, there is no explicit reference to the Standard Library. The question people are asking is, "Where the heck is it?"
Dave Payne, from Apple's Developer Tools team, kindly cleared away the mist:
With gcc on Mac OS X, the "standard C library" (sometimes known as libc on Unix systems) is part of System.framework, which is implicitly brought in by gcc when linking. System.framework is a dynamic shared library, shared by all apps on the system, which reduces overall system memory use.
If the application uses C++, gcc also automatically brings in /usr/lib/libstdc++.a, which is a static library. We currently recommend that developers avoid building frameworks (shared libraries) with C++ APIs, to avoid binary compatibility problems, because gcc's C++ ABI has been in some flux.
One other thing to note: for C & Objective-C APIs, we encourage the creation and use of frameworks. If someone does want to build a static library and link it into their app, they currently need to follow the standard Unix naming convention of lib<foo>.a. See this Q&A for more info: http://developer.apple.com/qa/qa2001/qa1101.html
Some of our conventions derive from wanting to help enable easy porting of Unix programs to Mac OS X; we need to balance the use of Unix conventions and Mac conventions, and try to make things seamless for everyone.
Interesting stuff. If you launch Project Builder, then click on the Targets tab, you'll see a list of various settings, as well as a sequence of Build Phases steps. Figure 1 shows the Frameworks & Libraries Build Phase. Dave's point above was that the Standard Library wasn't listed in this pane because it is built into System.framework and implicitly brought into the link process, not as an additional library added to the project.
Figure 1. Project Builder's Targets pane, showing no additional Frameworks & Libraries.
When I sent Figure 1 to Dave Payne, I asked him if Project Builder made use of makefiles. For you non-Unix folks, a makefile is a text file containing a script for building an application. Typically, a makefile will contain a series of build instructions, depending on the target being built. Project Builder's Target pane is, in effect, a graphical makefile. I was asking Dave if there was an actual makefile underneath it all:
Any other frameworks and libraries besides System.framework and libstdc++ will appear in the area you show in the screen shot. The "Sources" Build Phase shows the compilation and link order of project source files.
No, there is no makefile under the interface that folks can look at. The internals of the build system are an implementation detail which we may change in the future. A developer can look at the detailed build log if they want to see the actual commands that get run during a build. To see the detailed build log, drag up the split bar at the bottom of the build pane so that the summary is at the top and the detailed log is visible below.
To get a sense of this, check out Figure 2. It shows the Build window from the Hello, World project with the split bars dragged wide open to reveal the Build specifics. Personally, I'd like to see this process opened up a bit more so I might tweak my compile/link instructions directly. Perhaps in a future version of Project Builder.
Figure 2. The Build window from our Hello, World project.
Play with Your Debugger
As promised, I'd like to spend a bit of time going through Project Builder's debugger interface. Launch Project Builder, then select New Project... from the File menu. Our last Project Builder effort was a project of type "Standard Tool". This was equivalent to a Standard Library based C console app. This month, we'll create a project of type "Foundation Tool". Name the project Hellobjc and store it in the same directory as your other projects.
The Foundation Tool project is based on the Foundation object framework and links in the Objective-C library. Over time, we'll tackle the syntax of the Objective-C language and become familiar with the classes that make up the Foundation framework. For now, let's play with this project and see if we can't learn a bit about how the debugger works.
In the project window, click on the Targets tab (the tabs are arranged vertically - sideways) and the Targets tab is fourth from the top. In the list that appears, click on the Hellobc target (you may need to click on the Targets disclosure triangle to reveal the Hellobc target). In the new pane that is revealed, under Settings, then under Simple View, click on the item GCC Compiler Settings (Remember last month's Terminal project? You compiled your source code with the command "gcc." GCC is the GNU C Compiler).
Make sure that the "Generate debugging symbols" check box is checked. This tells project builder to include debugging information when it compiles your code, allowing you to use the debugger to debug your program. Very important! Take a look at Figure 3 to get a sense of what this looked like on my machine.
Figure 3. Make sure the "Generate debugging symbols" checkbox is checked.
Before we try out the debugger, take the program for a spin. Click on the icon with the tool-tip "Build and run active executable" (check out Figure 4). The Build window will appear and the program should compile and, finally, the Run window will appear showing our classic "Hello, World!" output, much as it did in the C-based Hello, World project.
Figure 4. Click on the third icon to build and run your project.
Now close the Run and Build windows, leaving the Project window open. Click on the Files tab, then select the file main.m (you'll find it under Source). As a reminder, Objective-C source files end with the extension ".m". Here's the default source code from main.m:
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
// insert code here...
NSLog(@"Hello, World!");
[pool release];
return 0;
}
Let's replace the "insert code here..." comment with a simple for loop we can follow in the debugger. Here's the new version of main.m:
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
// Adding a for loop for debugging fun...
int count;
for ( count=1; count<=3; count++ )
{
NSLog(@"Hello, World!");
}
[pool release];
return 0;
}
Note that we replaced the NSLog() call in the original code with a loop that calls NSLog 3 times. Run your new code. You should see the familiar console window, but this time with 3 lines of "Hello, World!" NSLog() is a function you can use to get output to the console window and the square brackets are mechanisms you use to send messages to objects designed to receive those messages. In the code above, we send an "alloc" message to the NSAutoreleasePool object, then send the resulting object an "init" message. When we are done, we send the object a "release" message. Not to worry, we'll start digging into this syntax next month.
For now, let's take this new code for a spin in the debugger. Close your Run and Build windows (not necessary, just doing this to avoid confusion). In your Project window, note the blank column just to the left of your source code. This column holds your breakpoints and tell the debugger when to stop and wait for your input.
Click just to the left of the for loop to create a breakpoint there. Figure 5 shows the breakpoint icon that appears.
Figure 5. Click in the source code to create a Breakpoint.
Now lets run the debugger. Click on the hammer/spray can combo icon in the upper-left of the Project window. The debugger window will appear (Figure 6), the program will start running, and the debugger will stop at our breakpoint, immediately before executing the for loop. Notice the pink highlight bar that highlights the line of code that is about to get executed.
Figure 6. The debugger, stopped just before executing your for loop.
Now step through the execution of your program using the controls that appear in the upper right corner of the debugger window. The triangle restarts execution from the beginning of your program. The second icon, pauses execution, just as if the program had hit a breakpoint. The next icon resumes execution until the next breakpoint or until your program exits. The fourth icon is one you'll use a lot. Its tool-tip says "Step over method or function call." Basically, it tells your program to keep executing to the next line of code in the current source file. If the current line is a function call, it completely executes the function call, stopping before the next line of code after the function call.
Figure 7. Click "Step over method or function call" to go to the next line of code.
The next icon actually steps into the function, stopping at the first line of code within the function itself. The last icon finishes execution of the current function, stopping at the next line of code within the calling function. Add a function to the code and give these controls a try.
As you might expect, the fields that show the variable values update as you step through the program. Notice that the variable count starts with a value of 0 and then increments each time through the loop. You can add breakpoints during execution by clicking next to a line of code in the breakpoint column. Want to get rid of a breakpoint? Click and drag to the left or right. Move a breakpoint by dragging up or down.
To view your Standard Library output, click on one of the two tabs towards the upper right corner of the debugger window. The Console pane is a log of important debugger events interleaved with your standard i/o. The Standard I/O window is pure, listing only the i/o itself, each tagged with a time-stamp and a code you can use to link a statement to a specific execution of the program. Each time you restart your program, the code changes, and all i/o from that run will have the same code.
Want to change a variable? Piece of cake. You can double-click on a variable's value and, when the edit field appears, type in a new one. You can also double click on a variable name and a new window will appear, letting you track that variable separately. Cool!
Till Next Month...
Spend some time playing with the debugger. Create some code (go back to a Standard Library tool if you are uncomfortable mucking with Objective C), add some functions, play, play, play. The debugger is an incredibly important tool and you should experiment with it until you feel comfortable using it.
See you next time!
Dave Mark is very old. He's been hanging around with Apple since before there was electricity and has written a number of books on Macintosh development, including Learn C on the Macintosh, Learn C++ on the Macintosh, and The Macintosh Programming Primer series. Check out Dave's web site at http://www.spiderworks.com
