Volume Number: 18 (2002)
Issue Number: 12
Column Tag: Getting Started

A Taste of Project Builder

by Dave Mark

In last month's column, we checked out http://developer.apple.com and downloaded and installed Apple's development tools. Since last month, I've gotten a number of emails from folks asking about other development environments, such as CodeWarrior, REALbasic and AppleScript Studio. Is Project Builder the only game in town? Absolutely not. Will we dig into these other environments? Absolutely.

The mission here is to cross the chasm, to get from Mac OS 9 to Mac OS X. There are a number of ways of skinning this fish and I want to explore them all, look at the advantages and disadvantages of each environment.

Know of a tool that I should be covering that has not been mentioned yet? Are you on the dev team at Apple, REAL, or Metrowerks and want to get the story out on your tools? If so, drop me an email at feedback@mactech.com and let's tawk.

I know that last month I said I was going to dig back into Project Builder this month. But I was playing around in the Terminal app and I thought you might appreciate a detour into the Unix command-line way of doing things. No matter how sophisticated the development tools get, it is important to connect the dots back to the Unix command-line. After all, the compiler that Project Builder uses is the exact same compiler we'll be using from the command-line. I promise, next month we'll get right back into Project Builder and walk through the debugger.

Start by creating a new folder to hold your source code. Next, use your favorite text editor to create a new source code file. Personally, I use BBEdit, but in a pinch, TextEdit or Word will do the job. Just be sure you save the file as a plain text file. No styles, no rtf, just plain text.

How to do this? In Text Edit, go to the Format menu and select Make Plain Text. Notice that your empty window is renamed to Untitled.txt (as opposed to just plain Untitled, which really corresponds to Untitled.rtf). For simple source code editing, this'll do the trick.

In Word, you can accomplish the same thing by doing a Save As... and selecting Text Only from the Format drop-down menu. Bottom line, your development environment expects a stream of plain-text characters and will make complicated squealing sounds if you feed it anything more complex.

Create a new text file, save it as "hello.c" and type in this simple block of code:

int main()
{
   printf( "Hello, world!\n" );
}

Note that this is a simple C program and we've used the ".c" extension to remind us that this is C and not Objective C. As we'll see in a bit, Objective C files traditionally end with ".m"

Now that your source code is entered and saved, let's drop into the Unix universe and compile and run the darn thing. Just so your source code will be easy to find from within Unix, create a new folder on your desktop named "hello" and drop your hello.c file into the hello folder. Now you are ready to launch Terminal.

You'll find Terminal inside the Applications folder, within the Utilities subfolder. When you run Terminal, a new Terminal window will open and you will be automatically logged in under whatever account you logged into when you started up Mac OS X. Typically, a Terminal session will start something like this:

Last login: Fri Nov  8 17:56:05 on ttyp1
Welcome to Darwin!
[David-Marks-Computer:~] davemark%

The first line should reflect the current date and time, and the last line is your prompt. In my case, the prompt consists of the current directory in square brackets, followed by my login name and the percent sign "%". Don't worry about the specifics for now. In a future column, we'll spend some time looking into a variety of Unix commands. For now, we just need enough to get the job done.

The program that prompts you to enter your Unix commands is called the shell. There are a variety of shell programs out there, all of which do the same basic task, prompting you for input, then taking action based on that input. Though on the surface they might all look the same, there are some big differences between shells. The Bourne shell is the most basic (and typically uses a "$" as its prompt). The C shell (seashell, get it?) is a next generation shell that is actually about 20 years old but is still widely used. The bash shell is based on the Bourne shell (bash stands for Bourne-again-shell. "Bourne-again" - get it?) The tcsh shell is the default shell for Mac OS X users and is likely the one you are using.

Wanna check to see what shell you are using? Go into the Applications folder, then into the Utilities subfolder and run the NetInfo Manager utility. NetInfo is a database manager. Much off the system configuration info is stored in a NetInfo database. To find your shell setting, click on users in the first column, then on your user name in the second column. In the bottom half of the window, scroll down about half-way. You'll find the word shell listed in the Property column. Look for the shell setting in the Value(s) column. Mine is set to /bin/tcsh. My guess is, yours is too.

At the prompt, type the command "pwd" followed by a carriage return:

[David-Marks-Computer:~] davemark% pwd
/Users/davemark

The command pwd stands for print working directory and asks the shell to list the path to the current directory. By default, this is your login directory, typically /Users/xxxx where xxxx is your login name. You can view this directory in the Finder by opening a Finder window and clicking the Home icon. Same place. In my case, pwd prints out "/Users/davemark".

Next, type the command "ls", which asks for a list of the contents of the current directory:

[David-Marks-Computer:~] davemark% ls
Desktop   Library   Music     Public    Sites
Documents Movies    Pictures  SME

Note that one of these files and folders is the Desktop directory. That's the one we're interested in. Type "cd Desktop" to change directory into the Desktop directory (to make the Desktop directory the current directory):

[David-Marks-Computer:~] davemark% cd Desktop

Now do another "ls" to see what is in the Desktop directory:

[David-Marks-Computer:~/Desktop] davemark% ls
October2002DevToolsPatch.dmg            hello

Being the neat and tidy person that I am, I only have two files on my desktop. One is the October 2002 Dev Tools patch I downloaded from developer.apple.com. If you don't have this patch already, go download it (unless of course there's already a newer patch on the site) and apply it to the tools on your hard drive.

The other item on my desktop is the hello directory in which I placed my source code. Now let's "cd hello" to drop into the hello directory, then do a "pwd" to verify that we are in the right place:

[David-Marks-Computer:~/Desktop] davemark% cd hello
[David-Marks-Computer:~/Desktop/hello] davemark% pwd
/Users/davemark/Desktop/hello

Looks good. Note that we also could have entered the command "cd /Users/davemark/Desktop/hello" and we would have winded up at the very same place. We just descended into this directory one level at a time so you could get a better sense of what we were doing.

Enter an "ls" command to verify that the source code file is inside the hello directory:

[David-Marks-Computer:~/Desktop/hello] davemark% ls
hello.c

Yup. It's there. Now we can compile the code. Here's how we do it:

[...Desktop/hello] davemark% gcc hello.c -o hellotest

The command is "gcc" and the arguments it takes are "hello.c", "-o" and "hellotest". Without getting into too much detail (we'll do plenty when we really start digging into Unix), we've asked the compiler (a program called "gcc") to compile the source code in the file "hello.c" and to save the output in a file named "hellotest".

Actually, The real command is gcc3, but Unix makes aliases to this command (called a symbolic link) with the names "cc" and "gcc". In the olden days, there was only one C compiler for Unix and its name was "cc". Not so many years ago, the GNU folks (GNU stands for GNU is Not Unix - recursive, get it?) made the gcc compiler available and it made its way into many versions of Unix, especially systems based on the Linux kernel. More on GNU, Free Software, and Linux in a future article. If you have access to the Sundance Channel on DirecTV or the like, look for a movie called Revolution OS. A great little documentary.

Want to prove that cc and gcc all link to gcc3? Use ls. Here's how I did it:

davemark% ls -l /usr/bin/cc
lrwxr-xr-x  1 root  wheel  4 Nov  8 22:49 /usr/bin/cc -> gcc3
davemark% ls -l /usr/bin/gcc
lrwxr-xr-x  1 root  wheel  4 Nov  8 22:49 /usr/bin/gcc -> gcc3

To learn more about the gcc3 compiler, read the release notes. You'll find them on your hard drive in:

/Developer/Documentation/ReleaseNotes/GCC3.html

Now type "hellotest", to see if this worked:

[David-Marks-Computer:~/Desktop/hello] davemark% hellotest
hellotest: Command not found.

This may have worked for you, but most likely you got the error "Command not found". Basically, your shell is telling you that it doesn't have a command named "hellotest". Every time you type a command at the shell prompt, the shell looks through its path list to see if it can find a program with a name matching the command you just typed. It has a set of directories that it always searches to find commands. Unless you specifically tell it to, it will not look in the current directory for commands. To force it to look in the current directory for hellotest, type "./hellotest", where the . stands for the current directory:

[David-Mar...puter:~/Desktop/hello] davemark% ./hellotest
Hello, world!

Hey! It worked! Cool! Check out Figure 1 to see this whole sequence in a single Terminal window.

Once you know C, you have come a long way towards learning Objective-C. Objective-C is basically C with objects added into the mix. Let's rename "main.c" to be "main.m". Remember, Objective-C source files traditionally end with ".m". Use the "mv" command to rename the file:

[Davi...uter:~/Desktop/hello] davemark% mv hello.c hello.m
[Davi...uter:~/Desktop/hello] davemark% ls
hello.m   hellotest

Now we need a slightly different compile command, one that knows we are compiling with the Objective-C library:

[Da...:~/Desktop/hello] davemark% gcc hello.m -l objc -o hey
[Da...:~/Desktop/hello] davemark% ./hey
Hello, world!

Every so often someone asks me what languages to learn first in order to become a Mac developer. With the release of Mac OS X, the choices have shifted. There are choices like REALbasic and AppleScript, as well as a variety of shell languages and web-focused languages (Perl, JavaScript, PHP). And, of course, the languages Objective-C, C++, and Java.

If your goal is to become a professional Mac OS X developer, you should become familiar with all three of Objective-C, C++, and Java, so you can make the right choice of languages when the time comes. But (and here's where the controversy kicks in), I strongly believe you should first give yourself a grounding in C, the language on which these other three are based. I believe it is critical to understand where C leaves off and where these other languages begin. Given that Objective-C, C++, and Java all support a different object model, all they really have in common, syntactically, is C. There are about a million great C books out there and, if you don't have the bucks to spend, there are some on-line tutorials for C that are free.

Learning C might seem like a waste of time, especially given that you can't produce an actual Mac OS X Cocoa app written in C, but it is not. Learning C first is both modular and efficient. C is pure procedural language. The others add the concept of object programming into the mix. Simplify the learning curve. Learning pure C is simpler, plus you'll add another language to your arsenal. And best of all, once you know C, learning these other languages will be much simpler. C is a great foundation language.

So listen to your Uncle Dave and learn C first, then tackle Objective-C. Then you can play with C++ and Java while you are also learning Cocoa, REALbasic, PHP, etc.

The command "gcc hello.m -l objc -o hey" tells the compiler to compile the source file hello.m, linking with the objc library, and producing an output file named "hey". We then run "hey" and it produces the correct results. Cool! Our first Objective-C program. Not much Objective-C there, but we've learned a couple of things. A bit about Unix, the fact that when we installed the developer tools we are able to access them directly from within a Unix shell, and the important fact that Objective-C is, in effect, an extension of C.

It is definitely worth your while to become comfortable with the Unix command line. Commands like pwd, ls, and cd might seem arcane, especially when compared with the beauty of the Mac OS X gui, but it is important to be able to lift up the hood and tinker with the innards. There are a number of terrific books out there for learning Unix. If you go to the bookstore, head for the Unix section and check out the Unix "how to use the shell" books, as well as a general Unix overview book. There are a couple of Mac OS X-specific Unix books that are due for release around this time. Those might be good to add to the collection. On the other hand, there's a ton of good sites on the web. I'll try to gather some good URLs on spiderworks.com.

Next month, we'll dig into the debugger. Until then, why not spend a bit of time digging through some Unix documentation and, if you have the spare cycles, start plowing through some of the docs in /Developer/Documentation/. See you then...

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