Welcome. Good afternoon. Boy, these lights are horrible. There's a lot of you here today and I'm hoping that you have a good time listening to this discussion. The development tools are the key. Development tools are what will make Mac OS X successful, will make your application successful, and will get us all to the place that we want to be. So without further ado, I want to introduce Dave Payne, the manager of the Development Environment Team.

Thanks, Jeffrey. All right, great. Okay, let's go ahead and get started. So what we're going to take a look at today is the power of Project Builder. What you can do with it, how to do it. So we'll go through a number of things. Basically walking through all the features of Project Builder for creating, editing, and navigating your projects.

Take a look at source code management from within Project Builder. Configuring, building, and debugging your targets for building products. And then, so a lot of what we're going to do really is kind of walking through a lot of the features, make sure that you know what exists. Maybe for those of you who've used it, it's some review for some of that.

In this particular session, more than most, or more than hardly any in this conference, we are going to be talking a little bit about future stuff. We will discuss what's new in Project Builder on the developer tool CD that you received when you registered or when you walked in this morning. And then, as I mentioned, we'll talk about the future of Project Builder to show sort of where we're going with this.

So let's go ahead and get started on what is Project Builder. So Project Builder is our integrated development environment for Mac OS X from Apple. With this, we build all of Mac OS X. Carbon applications such as the Finder, Help Viewer, Sherlock are built with Project Builder. Cocoa applications, our favorite, Project Builder itself is built with Project Builder.

Interface Builder, Mail, the WebObjects tools, a lot of very heavy use of Cocoa within Apple. There's a full Java 2 environment that you can develop with Project Builder. And now on the May 2001 Developer Tools CD, you also have the ability to develop WebObjects 5 applications. So that's a lot of what we've been doing for that.

You can develop Unix tools, such as daemons server process, you might want to build tools that then you access from graphical applications. You can build kernel extensions and device drivers. So really the whole spectrum of everything that you can do with Mac OS X, you can do it from Project Builder. But a lot of times you don't create source from scratch, so there's a number of ways that you can get source code into Project Builder from other places. And I'll talk a little bit more about that later on.

So Project Builder is really the centerpiece of our development environment strategy at Apple. It's your development hub. We've been working very heavily with a lot of other teams within Apple to ensure that Project Builder integrates well with those other applications that others are working on. So for instance, we interface with Interface Builder, which is our user interface construction tool for Cocoa and Carbon applications.

You can hear a lot about that in the next session in this hall. New again on the May 2001 Developer Tools CD, we integrate with WebObjects Builder and EO Modeler, and the WebObjects team will be showing that off in a lot of their sessions throughout the course of the week.

We also interact with the WebObjects team. So Project Builder integrates well with the WebObjects team. We've been working very heavily with them. We've been working very heavily with them. So Project Builder integrates well with the WebObjects team. We've been working very heavily with them. We've been working very heavily with them.

interact with the file merge tool for graphical comparison of files, and with a lot of the performance tools such as Object Alloc and Malloc debug. So we have integration with some of these at this point. We intend to have further integration with others as we move on in the future. Plus, there's some other things that we're -- teams we're working with that aren't yet depicted on this list.

So sometimes in the email lists and other places people ask me, so can I really use Project Builder for my big applications? And the answer is emphatically yes. We use Project Builder for over 250 projects that feed into Mac OS X within Apple. They are across the board from applications to frameworks, plug-ins for all the screen savers and system preference panels, all of our device drivers, everything else goes through Project Builder.

So it's really in very heavy usage and that's great for us. We really try to establish tight feedback loops with those teams so that if they have a problem, we send people over, we work with them to ensure that we can solve those problems and get developers past that. And that helps us deliver a better product for all of you as well. Project Builder also really facilitates team development. It's pretty rare that you have on a major application just one person working on it. So of course as you would expect.

There's preferences for the application. But something kind of innovative, every developer on a project has their own user settings for that particular project that's stored within the project files directory. It's one of our wrapped directories. So each of you has a separate file there, which means that with our integration with source code control, you can actually check the files. Your settings files.

So you can delete the whole project off the disk then. And then six months later if you have to come back and do some maintenance, then all of your user settings are still there. So there's editor settings, build settings, and debugger settings are all stored on a per user basis. And we'll take a look at some of those as we go through here. So before I get into the meat of the product itself, I'd like to talk a little bit about the evolution of Project Builder. Where are we and how did we get here?

So we kicked this project off two years ago in February of 1999. The first code was written, the first lines of code. There were two engineers on the product at that point. It's been my pleasure to build the team over the past couple of years, transitioning people from our older Project Builder WO, older IDE, onto this and hiring new people internally. Steve Naroff mentioned this morning in our tools overview that we're continuing to heavily invest in tools. We've actually had five new engineers join the team since February of this year. There's other new employees out in the audience. Hi, welcome.

So I'm really looking forward to the power of this team, what we can do moving forward. In February of 2000, we started rolling it out with an Apple. We had been using it before that, but now we start asking other people to use it. The March 2000 version that you got on the, 2001, you got on the developer tools CD and the original Mac OS X is our version 1.0. It's a fully usable product. You can use it for all your development. But again, we've got our first up to date version. So we're going to get into the first update here in May 2001.

The WebObjects 5 support, but there's a number of other general purpose fixes as well. And we are going to be doing new improvements, new releases on a regular basis for the product. So you should see things coming out well for us. Okay, so now let's go ahead and start taking a look into the product itself with creating, editing, and navigating projects.

So to help me do that, I'd like to bring on stage Mike Ferris, who now works for me as the manager of the Project Builder team itself. So I have the Project Builder team, the compiler team, debugger and performance tools, and a QA and integration team. So Mike and I have been working together for a while. We're going to do a walkthrough of the features of Project Builder.

So the way we're going to do this... If we can go ahead and have a demo on the other screen. Now for those of you sitting in the far wings of the audience, you may want to move in a little bit because we are going to do slides on one screen and demo on the other.

So let's take a look at the overall user interface first. So we've got a project window open here. On the left side of the window are the project structure panes. So this is where we keep information that's stored on disk about the structure of your product. So the groups and files outline is first shown.

Below that we've got bookmarks for navigating through your project, then targets to represent your build products, and then breakpoints for debugging. On the right side of the window we've got editor panes with a navigation bar at the top of each editor pane. We'll talk a lot more about that.

At the top of the window, we've got a toolbar that's now a configurable toolbar just as in the Finder and in Mail, and many of you may want to take advantage of that in your products as well. This is using facilities provided to us by Cocoa. We'll be providing additional icons to add more facilities to let you customize your toolbar as you'd like over time.

If you bring down the tool panes here, above the editor panes, we've got tools for project-wide find, for build output, for the console output, input and output when you're running a product, and for the debugger. How do we create a new project in Project Builder? So if we go up to the File menu and bring up the New Project menu item, we can see that the New Project dialog comes up. It's got a lot of different project types listed here. So applications, bundles, frameworks, kernel extensions, and I/O Kit drivers, tools, really everything that you want to do on Mac OS X.

Within each of these, we have different subsets of these as well. So you can do Carbon applications or Nib-based Carbon applications. You can do Cocoa applications or Document-based Cocoa apps if you're using the NS Document model. So sometimes we get the questions on the list of, "Gee, this is my first experience with it. I want to create a C++-based tool. How would I do that?" Well, maybe the C++ tool item is a good choice. But let's go ahead and create a document. a document-based Cocoa application.

So taking a closer look at our groups and files outline here, we can see that this is just a user-definable grouping of files. If you have experience with our previous version of Project Builder, this is much more flexible now. The files here are completely independent of the physical location on the disk.

It's independent of any particular restrictions of the build system. So you can reorient this however you want. You can move files around just by dragging. You can select groups or files and just delete them if you wish. You can select multiple files and put them into a new group through the Project Group menu item. Hey, you can go back and ungroup it again.

So you can also add new files to your project or add new frameworks, so link against new frameworks. To add a new file, you can either go to the project menu and use add file or add frameworks, but you can also drag in from the finder. So in this case, we'll take an icon file and drag it into our resources group here in our project.

Now when you add a file, it asks you, do you want to copy this item into the group or into your project hierarchy, so if it's somewhere else on your system. Typically, you'd probably want to say yes. It also asks you what targets you want to add the file to. So in this case, we only have one target. If we add more, you can choose to add it to multiple targets right at that point.

So, among the other things that Groups and Files Outline gives you access to is you can navigate down into your frameworks if you'd like to take a look at what headers do I have available to me in this framework. So, this is one of the mechanisms for getting to headers. There's a number of others as well. So, in this case, we're navigating down into the foundation headers. So, we can see that those come up in the editor, a whole list of those.

Also, then, this is especially interesting. Besides frameworks, we've also got your built products there. So, we can see down here a products group that Project Builder has created for us. Well, that's interesting that foo.app is shown in red here. Now, that's because foo.app doesn't yet exist on the disk because we haven't built this project yet. If I had a file that was deleted from the disk or doesn't exist, that would show in red as well, and you might need to fix up the reference to that.

But in this case, we can fix up the fact that the app doesn't exist by building it. So, if you remember, this was a Cocoa document-based application that we had created. And now we go off and build, and the build tab came up to show us the build output, and we closed that back up.

Now we can go down into the products group and navigate down in and see the bundle contents here. So, an application package on the build tab is a package that we can build. So, the package on Mac OS X is a bundle. You've heard a lot about this. You'll hear a lot more about it. So, within here, we can see the Info.plist.

So, we can click on that and see the XML of that. Project Builder took the information that you had supplied in the project, which in this case is default, and created that for us. We've got the Mac OS X directory that the binary for Mac OS X is in here. There's the pkg info file that's necessary.

There's the pkg_finder_launch_services to find this application package as an application. And then there's the whole resources group as well, with, in this case, English resources. So, if you had your project localized into multiple languages, this is where you would see the .l projects for your different languages. So, we'll be enhancing this facility over time to give you full inspection of the built results of your project. So, you can envision things like the size. The size of the binary and the groups and permissions and things like that.

So let's take a look at some of the capabilities of the editor. So we'll go back to the more complex Sketch project here that we've already had open. So Sketch is one of the example projects for Cocoa. It's an NS document based project that's out in developer examples Cocoa.

So we can select a file and we can see that we've got full syntax coloring here in the file. We can do things like splitting the window by going up here to the split bar or split icon. We can resize each of the split panes. We can create more if we want. We can close up any particular split panes.

Now a lot of people are looking for more flexibility in the environment. So what if I don't want to be constrained inside that window? Well you can bring up files in other windows by just going and double clicking in the outline view and now it comes up in a separate window.

You've got all the same capabilities here where you can split the editor pane. Each of the editor panes has a navigation bar here so you can flip between different files, show the same file, different parts of the same file, or you can show different files in the same editor pane. pain.

Some people occasionally ask us, is there a facility for showing what line number I'm currently on or going to a specific line number? So to go to a specific line number, let's bring up the go-to line menu item under the find menu. And Mike, what line number should we go to here? Oh, I don't know. How about 20? Line 20.

Sounds good. Okay, so we go directly to that. Now, also we find that if we keep that window open and we move around between the file, the auto-update is almost barely visible on the screen up there. So clearly this is an opportunity for some future improvements in the product here.

Now, when you're editing, there's a number of different parameters you can set for the text settings of the files. So we can do this by selecting a file and then going up into the project menu doing Show Info to bring up the file inspector. So we can do things like set the tab width, set the indent width.

You can set the end of line characters. So do you want to use the Mac end of line carriage return character or do you want to use the Unix end of line character, which is a line feed? And in the case of-- We've actually enhanced the preprocessor, the compiler, and the debugger to be able to handle either of these properly. But you may find that if you're going to work with Unix tools with your files, for example, run Perl scripts across them to look for word counts or something, you might want to switch to using Unix end-of-line characters. You can also set the file encodings.

So let's say that you wanted to put kanji comments into your source code files. Well, we've got a whole set of different file encodings here. If you switch to UTF-8, then you can represent Unicode characters in files that can still be processed by our compiler tool chain properly as well. Go ahead and put all the kanji comments in that you want.

Other capabilities from the Inspector here is that you can change the reference style for how we're accessing this file on the disk. So you might want to have the file be relative to the group that contains it in the Groups and Files outline. So you can say that a group matches up to a specific folder on the disk, but you don't have to. You can also have a file be relative to the project that contains it, or you can also say that it's an absolute path.

So if you're going to be moving a project around at all, or moving it between machines, you'll probably want to use one of the relative reference styles. Now you've heard me talk about the fact that your applications can be localized into multiple languages with our bundle facilities. This is where you would do this in Project Builder. So we can select a Nib file here, which is one of the document files of Interface Builder. You can see in this case that we've got an English localized variant of this, as opposed to it being completely global.

So we can select that Nib file and say that, well, actually we'd like to add a localized variant here. So, Mike, what should we put here? Let's try Japanese. Okay, let's try Japanese. So we can add a Japanese localized variant to the file, and now we've got two localizations of this Nib file.

So one more thing to note about this, actually you can also switch things to be global resources again. One more thing about the groups and files outline that you should know is if you go up to the very top of the groups and files outline and select the topmost item, basically the root group, in this case Sketch, now the inspector changes to show that we're inspecting the project itself.

So I'll touch on this a bit more later in the talk, but this is where you would set a build location for this project specifically, and I'll talk about why you might want to do that. And it's also where you would select to commit changes for SCM across the entire project.

Now let's talk about navigating through the project. In order to use some of our more advanced navigation facilities, you first need to index your project. So currently with the shipping versions of Project Builder, we don't index by default. So if you wish to index, you go up to the project menu, select index project. This goes through the compiler to index all the C-based languages, so C, C++, and Objective-C. It uses a separate parser for Java.

If you do have any problems indexing in this current version of Project Builder, you should go to the console and look at that. We aren't currently invoking the build system in quite the same way as when we invoke to build your project. That's something we're going to be fixing in the next release. As I mentioned, the index is then used for some of our more advanced navigation mechanisms. But let's talk about navigation as a whole first.

So for moving around between files, in the navigation bar above each editor pane, we have a pop-up menu to show the recently viewed files. So you can move between those. There's also back and forward buttons, so you can move back and forward as in a web browser, kind of a stack-based there.

You also have easy access to included files. So we have what we call the counterpart button here and an icon on the bottom. And there's a button on the right of the navigation bar that lets you switch between, in this case, the class file and the header file for that particular class file. So we can move back and forth there. But if you've indexed your project, this is a little bit of a hidden feature. If you hold down the mouse button on the icon, the counterpart icon, that shows all the files that this file is including.

So we can go from this source file to one of its header files. And the other thing is now you can walk up and down your include hierarchy. So you can see that this header file is being included by two of the source code files. We can also go to on up the header hierarchy and say, well, let me see. Gee, we're importing appkit.h. Let me see what all it imports. And from there, that's another mechanism to get to framework headers. So a way of seeing the header file dependencies in your project.

For navigating within a file, we have, again, if the project is indexed, we've got the symbol pop-up here. So you can move between different methods within this file. And if you're in the source code and you see a method that you want to see, say, let me see the definition of this method. So shared print info here, if I want to see the definition of that, we can do a command, double-click on that, and that takes us to the declaration.

If we had multiple declarations of the same function, then it would put up a little pop-up menu if there's a small number of them. If there's a lot of them, it would actually populate the find panel and pop down with that, and you can select any lines there.

So, I think that covers that. So, another navigation mechanism is bookmarks. These are completely under your control. Each user has their own set of bookmarks. So, to set a bookmark in your project, you would select a line of code and then go up to the Add to Bookmarks menu item in the navigation menu. So, we can add a couple of bookmarks.

Now, if we go over here to the Bookmarks tab, we can see that this is a way of navigating around between different locations in our project. So, we can actually rename those by holding the Option button and clicking. So, you can, if you're working on a large project and you're working on specific parts of it, you can set up bookmarks to easily allow you to jump to that. So, again, because this is on a per user basis and multiple users will work on different aspects of the project, each person gets their bookmarks saved persistently with the project. They can be checked into CVS, et cetera.

Um... Okay, we also have a project-wide find and replace capability here in the find panel. So there's a lot of power built into this. We can control how far we want to search, so the search space here by going into the find options. So you can say I just want to search in this project, or I want to search in all of my open projects, or I want to search in my projects and my frameworks or just my frameworks. So there's a lot of control there. So you can set up individual find sets. You can set up individual find sets however you want for that.

So if we close that back up, we can see that we've also got different types of searches that you can do. So textual or regular expression for just plain string searches. If you've indexed your project, you can do definition searches as well and switch to finding the definitions of methods. So let's look for init with frame.

And we can see here that based on the find set that we had selected that we are seeing all the init with frame methods both from Cocoa framework headers themselves and from my project. So when we click on a method there in the find pane, it takes us to that implementation or declaration in the source code. Okay, so that covers that for our initial creating, editing, and navigating projects walkthrough. Thanks, Mike. If we can go back to slides on both screens, please.

I generally don't do these things where I talk all the way through. Bear with me. So now let's take a look at some of the source code navigation or source code management facilities of Project Builder. So, currently Project Builder interfaces with one source code management system and that's CVS.

You may have heard of CVS or you may not have. It's the concurrent versioning system. This is an open source source code management system that's used for a lot of the open source projects out there. It's cross platforms. It runs on a whole variety of different systems, a lot of different Unix platforms, Windows NT, there's clients for the Macintosh.

It comes on the developer tool CD, so when you install the developer tools you get CVS. We use it very extensively for Mac OS X within Apple, which for us allows us to test our Project Builder interfaces with this very well. And if you're going to be working with the Darwin sources at all, you may already be familiar with CVS because the Darwin sources are kept in CVS repositories and you can access those out on the network and check out the Darwin sources directly. time.

So there are some places you can get documentation for using CVS in Project Builder. We put the manual on the system itself in Developer Documentation Commands, CVS. I think we'll have URLs for this type of thing later up on the web. Also, if you go to Project Builder's Help menu, in the Projects section, there's a Source Code Management section there that covers a lot of what I'm going to talk about.

So in order to use CVS within Project Builder, there's some things you have to do to set up for this first. Number one is you have to have a CVS repository somewhere that you're going to be storing your project in. Typically there's one CVS repository for a whole group of developers.

We have about three of them within Apple. So the Darwin CVS repository, CoreOS has one, and then everybody else has one. You can use either local access to that and NFS access to that. CVS looks local. Or you can use client server access to a remote CVS repository.

It could even be on a different type of machine, but of course you'll want it on Mac OS X. For remote, you can use P server authentication or with the new system, sorry, I jumped again there. You can now use SSH authentication as well. Another requirement is that your project already has to be in CVS. We'll be enhancing some of these things in the future, but for now this is the way that you would use it. So from the command line in a terminal window, for example, you would do a CVS import on your project to add it to the repository.

And then you have to check it back out of the repository into a CVS working directory. So on the command line, check it out. Some people on the email list ask, gee, Project Builder doesn't seem to have my SCM menu enabled. Why is that? A lot of times it's because you don't have your project in a working directory. Maybe you haven't yet put it into CVS. Those are some of the precursors. And one thing I forgot on here is that you actually have to have your CVS root environment variable set up properly, I believe. And that's documented as well.

Once you've done this, then there's menu items for committing changes on selected files or if you have groups selected, it commits all the changes and files that have been modified in that group. If you want to commit everything in your project, including the project file itself, you would select that type.

And then you have that top level group that I showed in the groups and files outline. When you commit, that makes the addition and removal of files permanent. But before CVS knows about the addition or removal of files, you have to tell it. So there's an add to repository menu item or you can just delete files.

The SEM status of files is shown in the Groups and Outlines view. So there's modified. U means that it's updated out in the repository and you need to update to it. Somebody else has changed it. Question mark means it's not yet in the repository. A means that you've added it and will be committed later. R means that it's been removed. So it shows in gray there. And check my time here.

The C means there's been conflicts. So you can also compare different revisions of the files through file merge. You can look at the change logs in the file inspector to see all the different revisions. You can compare with the base revision of a file. You can compare with the latest revision. If you're going to be checking in, nib files from Interface Builder. Mac OS X in a fair number of cases use what we call wrapped files or packages even.

What we do internally within Apple at this point is use what's called CVS wrappers. In order to do this, there's a configuration file that we supply in developer tools, CVS wrappers that you would need to commit into the top level of your CVS repository. And the CVS wrapper is the one that's going to be used to build the C++ application. So you can see the CVS root directory.

In client server mode, each user needs access to that. So you put it in a .CVS wrappers file in your home directory. This is all documented, actually in the last place we documented it, which was the release notes for public beta, which are actually still in the product as well. So I'd like to show a quick demo of source code management and the comparing of files here. So bringing Mike back up on stage.

So let's go back into the Sketch Project here. And if we open up, say, our Model Classes group, We can see here that when we open this up, there's a file here marked with a U. This means that typically we do check for SCM status when we open a group for the first time.

Remember the U meant that somebody outside had modified the file in the repository. So we'd really like to see, I don't really want to update to that until I know what they've done to it. So let's go ahead and go to the SCM menu item and do a compare with latest revision.

Now this will launch file merge. And we see in File Merge here that down in the lower left it shows that there's been one difference in the file that, wow, somebody added a new comment. Well that looks pretty important so we better update to that. So now let's go back to the SCM menu and we can do an update to latest revision. So bring in what's in the repository. If there were conflicts in that update it would show as a C. You could have used File Merge to do a merge of that as well.

Let's see. Demo scripts. Next time, now we're going to modify a file. Yeah, why don't we modify a file? That's a good idea. So let's go into Draw Documents and add an NSLog message here. So in Cocoa, this is a way, this is a foundation call that you can use to, it's like printouts essentially.

It comes out in the console. So we can add that. When we save the file, we can see that it's now marked in the Groups and Files outline as having been modified. And we can commit that by going up to the SCM menu item, Commit Changes, and enter a commit log. Personally, I like to commit things in sets. So things that had the specific change of one nature, commit them all together, have the same commit log and all.

So we can also inspect the file and see all the different revisions that we've had here in the SCM tab of the File Inspector. We've got essentially seven revisions since the 1.1. So let's pick a couple of those and compare them. So select a couple arbitrary revisions, hit Compare, and again this launches File Merge and shows us the comparison here in File Merge. In this case there's 10 differences and you can move between those. Okay, so that's it for our SEM demo. That's File Merge for you.

Now let's talk about configuring, building and debugging targets. So what is a target? Targets are really the face of the build system in Project Builder. A target just defines a product to build. A project consists of one or more targets, presumably. Probably wouldn't be that interesting to have a project without targets.

Targets can depend on other targets, and we'll talk about that. You can have build styles to allow different variations of the same target. This is a really innovative capability. Build phases control when you're building a project, a specific target, how does it get built. I'm not going to go into detail on this. You can learn lots about this in Project Builder in depth tomorrow morning with Mike and the team.

Each user has an active build style and an active target. So I might be building, working on the framework of the project. You might be working on the test tool of it, and he might be working on the app portion. When we build, it's a very simple process. that might do different things for each of us.

There's a bunch of standard types of targets, so we've talked a lot about apps, bundles, etc. You can add as many new targets to a project as you want by just going to the New Target menu item in the Project menu. There's a couple of special types of targets that we should highlight a little bit. We have aggregate targets that don't build anything themselves, they just express dependencies on other targets.

So this can be useful, let's say that I have a set of command line tools like the file commands on Mac OS X. You can put all those in one project and have an aggregate that builds them. It is useful to have that as the first target and I'll explain why in a couple of minutes.

You can also have, if you have, normally Project Builder controls the build system for you. You don't ever have to edit a make file or anything else. But there's a lot of power to change that if you wish with the build phases you can learn about tomorrow. You can also have targets where you control the build system or you're using open source projects and you don't want to change the build system that somebody else set up. You can just create a legacy make file for that and you can specify what build tool it is. It might be make, but it could be any other command on the system as well.

So let's look a little bit more at target dependencies. So you might have, for example, if your application is well factored, you could have an application and a test tool for it. So, for example, Project Builder itself is a small application that links with a few large private frameworks that have all the functionality.

And then we have tools that link with those frameworks as well. So in this case we have the My Framework target represented in the diagram there. My application depends on My Framework. My test tool depends on My Framework. You could select any of those as your active target and it would ensure that the framework gets built.

You could also have an aggregate that depends on all three here. So the aggregate, again, the aggregate doesn't build anything itself, but it ensures that the others get built. Having the framework there is optional from the aggregate because it'll get built once regardless. You can configure your target through the target editor.

We're not going to go through this in great depth, but I'll talk about different aspects of this. So to set up your build phases, indicating what files are in your target and how to process them, what source files do we compile, etc., you would go through the files and build phases aspect of the target editor.

For build settings, this is where you would control your compiler and linker options, things like your optimization settings, do you want to generate debug symbols or not, the install path of your project. And for advanced capabilities, there is an expert editor down there that lets you set any build variable and values for that. That can be useful in some circumstances.

The InfoP list that we showed previously in the new project that we had created, there's a bundle editor here or bundle settings that you can change the different configuration settings for applications, for frameworks, for bundles, for plug-ins. So you can set, for example, the identifier that the preference system would use, the type and signature for applications. You can set what the icon is. This is also where you would set up what the document types your project, your application could handle. So you can set up as a reader or as an editor of document types.

Or if you just want to put it out on the pasteboard, you can set it up with none if you don't actually handle documents of that type. Then for the debugging system, there's a number of things you can configure about how to launch your executable here for either running or debugging. So let's say that you have a plugin. So you have a plugin that you're working on and that's all that's in your project is a plugin.

Well, we can't just launch that and have it do anything interesting. So we have to specify an application as the context that that plugin would run in. This is where you would do that. You can hear a lot more about that in the debugging session on Friday morning.

All this ties into a very powerful build system that does automatic dependency analysis of your headers. Again, I've mentioned there's no make files to edit. We do leverage a lot of command line utilities underneath this. So Jam is a utility that's a lot like Make. That's what Project Builder calls, but very few of you should ever need to look at Jam files at all.

We talk to a lot of lower level compiler tools, so GCC for C-based languages, Res for .R files, Java C or Jyx for Java compiling. If you want lots of access to the full power of Unix underneath you, it's there for you, either in script build phases that you can put in, find more about that tomorrow, or the legacy make file targets that I talked about.

Where do build results go? So normally when you hit build in your project, it goes into a build directory in that project. But you might want to specify a common build directory for all of your projects. And this would allow Project Builder to-- let's say that you had multiple different projects where you've got an application in one project and it depends on three frameworks and you've got each of those in different projects. If you set them all up to build into the same place, then without actually installing that on your system, Project Builder can automatically configure the dynamic loader to find all of that, your development versions of all of that when you run.

So again, find more details on Friday about that. You would set that either for all of your projects in your building preferences panel or you might have sets of projects that you want to work on together. So put this set over here, put this set over here when you build. That's what-- when inspecting the project, you might want to set that up. You can change on each project's basis where that project builds to and that's why you would do that.

The compiler, I'd mentioned that we're using GCC, so we use GCC 2.95.2 currently. We build all of Mac OS X with this, so we've cranked a lot of code through this compiler, very heavily tested. It supports all of our C-based languages, and as you may have already heard, we are working on resurrecting Objective C++ to allow Cocoa applications to take advantage of existing C++ libraries. Go to the compiler technology session with John Graziano and company on Thursday morning to hear more about that. You've also got support for Velocity Engine in the compiler.

C++, GCC is a fairly strict about its anti-compliance on things. That's important to know if you're coming in from other environments. We've done some performance improvements for C++ code generation recently, so we've improved the exception handling and coalescing of symbols. So you can get more information about that again from the compiler session.

We are going to be working with the latest versions of GCC as it advances. So one thing that you should definitely know is that the C++ ABI, the Application Binary Interface, is changing between GCC 295 and GCC 3. So you don't want to have any shared libraries that export C++ API. Put a C wrapper around that.

Now I mentioned that Project Builder has been factored into an application and some frameworks. One of the tools that also links with those frameworks is called PBX Build. This allows you to do automation of your builds so you can have a Unix cron job going nightly to build all the sources of your project. Apple does this kind of thing with all of Mac OS X. We use PBX Build command to build everything. So again, this uses the same build machinery as Project Builder itself.

By default, if you just run PBX Build, it builds the first target in your list. So this is where having an aggregate here as the first target might be useful to you. If you want to make sure that all or most of your project gets built. The invocations of this look just like invoking make.

So PBX Build clean or PBX Build install. So if you're going to set things up to actually put them in to the install places you want, we don't currently have a way of doing this from the IDE. You would do this from the command line. Some people ask us, well why does it build into /temp? Well, we don't think it's a good thing to by default build what could be a buggy product directly into the install directories on your system. So we put it in /temp and the hierarchy there. If you want it installed directly when you build, set destroot equals slash.

For debugging, we have an extensible architecture that talks to GDB for debugging all the C-based languages, talks to the Java VM for debugging Java. It's full graphical source level debugging, so threads, stack traces, variables. You can have breakpoints that are saved on a per user basis. They're saved not only between different runs of the debugger, but between different runs of the IDE as a whole.

And again, I talked about how the Project Builder system controls the dynamic loader to use multiple projects at a time for debugging. So development versions of your frameworks. And for those of you who aren't familiar with GDB, it's a very powerful open source debugger that comes with the Mac OS X development tools, handles all your C-based languages.

You can handle arbitrary expression evaluation or invoke functions to get the values of open source. And it's also able to set opaque data types such as those from Carbon. You can set commands and conditions on breakpoints. And it's got a very powerful macro capability. Again, the debugger session on Friday morning, you can learn lots more about not only C language debugging from Project Builder, but Java as well. And lots about advanced features of GDB. So I'd like to show you some quick rounds of building and debugging demo here. So we can switch back to demo six, I believe it is.

So if we go back and bring up that Sketch project again, We had previously made some changes to the project, so let's go ahead and build it and see what we've got at this point. So we hit Build. The project was previously compiled, so in this case we do an incremental build with just the SKT draw document. We can close up the Build tab here because we got a successful build.

Now let's go ahead and run. So we can hit the little monitor icon there to run the application. So it fires up, brings it to the foreground, but we can see that in the run tool pane here, we got the console output from the NS log message that we had previously put in. So great.

But let's actually take a look at debugging. So let's quit out of this at this point and let's say that we want to debug the project. Now by default, when you build within Project Builder, it assumes that you're doing development. So it builds for debugging. That's why some of you look at it and say, "Why is my executable so large?" That's because it's got debugging symbols in it until you build for deployment, which we'll find more about that tomorrow. So... Sorry, I got ahead of myself here. Okay, so what I'd like to do is I remember that there were some issues there with the... Align Left Edges methods of Sketch. So let's go and find that method in the code.

We select the source for that and we can put a breakpoint here on that by clicking in the breakpoint well. Actually, why don't you bring up the breakpoints tab and just show that so now you can see where the breakpoint is listed there. You can enable or disable it. Let's go ahead and go back into the application.

fires up GDB on it and launches the project. So now we can draw a few objects here.

Couple objects and do a select all and then go and say align left edges. Boom, we hit the break point. Now we can see a variety of things here shown in the debugger. We can see that we've got the stack back trace where we stopped. So you can see some stack frames are shown in bold and some are in gray.

So we have source code for those that are shown in bold. For the ones in gray, they're in the frameworks. We don't have source code for that. We've got a threads pop-up to show the different threads in your application. Most Mac OS X applications have more than one thread, although keep it minimal.

We've got variable inspection here for all your different variable types. In the May 2001 tool CD, you can now set the values of variables when you're debugging in Java, and we have worked on that for C as well. If we start stepping through the code here, we can see that variables start to turn red if they've changed in the previous step.

So we can go down and look at first bounds and say, "Okay, here's a structure." We can see the contents of that structure. When we step over the line here that's going to set first bounds, it shows us that all the values of the structure had changed. And if we step through a little bit, for Cocoa programming, seeing the description of an object is a very important thing. So if you want to do that, what you have to do currently is bring down the GDB console, do a PO for Cocoa. Do a print object of a particular object.

So in this case, Curr graphic. We can print the object there. We'll be providing better user interface for this as well. And again, the debugging session will go into more detail on these things. And then if we were to step around the loop, we'd see it continue to increment the loop variables. So we can see that now I is on value two, for example. Okay? So that's it for that demo. Thanks, Mike.

Okay, let's take a look at what's on the May 2001 Developer Tools CD that you just got in your packet. Some of you probably had high expectations that, "Ooh, I hope my pet feature is fixed." Well, we've got full support for WebObjects 5 development here, so you can still do all your other development as well. But the primary theme again was WebObjects 5 for both Project Builder and Interface Builder. The WebObjects 5 developer packages themselves are included on the CD this time around. We don't plan to do that in the future, but we'll give exposure to WebObjects this time.

There's also a limited version of the runtime, so it's a time-limited, restricted version of the runtime that you can test your WebObjects applications with. There's new system documentation. There's some additional examples for AppKit, like I think one for the use of the app. There's also some examples for the NS Toolbar. And then some Interface Builder examples as well that Henri will probably talk about.

On the Project Builder enhancements, it's been localized into Japanese. General purpose enhancements, you can now continue your build after there's been an error in one file. So it can go off and continue to try to compile all your other files. That's on the building preferences. There's a check syntax check mark in the right portion of the navigation bar with which you can do, essentially, a single file compile check to make sure that you're using the syntax correctly. I talked about the precompiled, implicitly included header files. That's in what you've just received. There's build support for HeaderDoc and some bug fixes as well.

I talked about enhancements for Java so you can now merge JAR files automatically during the build process. There were a couple of problems with building large projects for Java, hitting command line length restrictions and things like that. Those have been fixed. And build performance improvements. So if you've indexed your project and you're getting, therefore getting Java dependency analysis, we now are again throwing multiple files at the compiler at the same time which processes them more quickly. There's build support for Java wrappers. So this is a Java wrapper around Objective-C frameworks. And I mentioned that you can set values when you're debugging Java.

So yeah, those of you who have used Help Viewer to try to access developer documentation, you can sometimes see that it might be nice to have faster, more flexible viewing there. And then some underlying support. I talked about Objective C++. One other thing we're working on is two-level namespace supports in the linker and loader that will let us add new APIs to our frameworks without breaking your applications by conflicting with that. So you can find out more about that in the compiler session.

So let's talk about the class browser a little bit. So Cocoa is a very big framework that's new to a lot of people. It's really not hard to learn Objective C, the language. But learning the frameworks is always the hard part. What can we do to help you there? So that's what a class browser can help with. For example, where is this class in the hierarchy? What's inherited, etc.? Let's see a demo.

So if we can switch back to demo, great. So going over to the other machine that's got the special sneak preview version here, we can see that we've now got a fifth tab here in the project structure tabs on the left. So a classes tab that when we bring this over, we can see that it's got the NSObject and NSProxy root classes for Cocoa. So we can navigate down in and see all the different subclasses of NSObject.

We can scroll down through that and see, for example, NSResponder. We might want to look at what's in that. And we can see that NSView here. So scrolling on down a little bit further, we can see, oh, hey, look, there's some classes highlighted in bold here. Now that indicates that they're classes that are actually in your project as opposed to in the frameworks.

So we can click on a class and we can see the members that are defined there. Click on one of the members and we can see the declaration of that. So that's pretty cool. But let's say that I knew the name of the class, but I didn't know where it was in the hierarchy. Well we've got some options you can set up down here in a pop-up to say, let's say, let's look at a flat listing of all the classes.

So now we see this all alphabetical, but wow, that's still kind of overwhelming. Why don't you just show me my project classes for now? And I see a list of just the projects in my class. So we can select one of those, say SKT Image, and we can flip back to the hierarchy here now.

And it shows us, wow, okay, that's a subclass of SKT graphic and you can look back through the class hierarchy. So if we were to Take a look at, I believe, next. See the inherited members. Inherited members, yes. So if we look at the options, there's a lot of power in this options panel. There's how you would set up the different option sets for the pop-up.

You can configure that. We'll have some default sets. There's a Show Inherited Members checkbox here. So if we check that, now we can see that in gray, we're seeing all the members that we're inheriting from the frameworks classes. So, but what are these book icons next to some of these? Let's take a look at one of those, Mike. So we click on the book for the class method and boom, the HTML documentation for NSObject shows up right here in Project Builder.

So we can also, because we had previously showed that files can be opened in separate windows, let's take a look at NS Bezier path off in a separate window. How would we do that? Let's just go down, double click on the book icon for set default line join style.

And off into a separate window, the HTML comes up. So you can copy and paste out of this multi-window. We're really working to integrate this seamlessly and well into Project Builder. So it's not ready to ship yet, but we think you'll like it when it gets fully there. Okay, thanks Mike.

So what else is on the drawing board? Well, one of the things we've heard loud and clear is that some of you would like more flexible UI. So, for example, we showed the tools panes coming down in the project window. It might be nice to be able to have those outside of the window and in general have a more flexible multi-window UI. Yes, we've heard that.

And yes, we'll be working on that. Other things, plug-in editors and plug-in build tools. We've been migrating the project towards that capability already. So the documentation viewing that you just saw is actually implemented as an editor plug-in. This is letting us get the APIs to a state where in a bit we'll be able to bring on, make those APIs more public.

We're looking for tighter integration with other tools such as Interface Builder and the performance tools so the ability to directly launch malloc debug or sampler or object alloc on your application from within Project Builder. And then on the compiler side of things, we need to do a lot of work on faster C++ compilation and we are also working on code generation improvements as well. So in summary, Project Builder is a very powerful idea. We're working hard to improve it in a lot of ways.

We've got a great team working on this and we're continuing to build up that team. Send us your feedback. Many of you already have been. And most important, finish up and ship your applications. So with that, that finishes up what I had to say. There's a variety of information pages out here. I'd like to bring Godfrey back on the stage for what remaining Q&A time we have. Thank you very much, Dave. I think we need a big hand for Dave and the Project Builder team.

I think the advancements we're making with Project Builder are more than just impressive and that it's going to be a tremendous tool for all of your use. This is just a roadmap to all the further tools-related sessions through the show. We felt that in this session it was useful to give this to you again so you have an idea where we're going. The next session in this hall is Interface Builder and we'll be doing a similar presentation. And now let's kind of walk through these.

That's my information in case you need to contact us. The Mac OS Tools feedback mailing address sends information to all of the development team on a one-by-one basis, feature requests, feature enhancements. Remember also to file bugs. When you run into bugs, use the bug reporter. It's fully accessible for this project.