Gentlemen, please welcome Cocoa Developer Tools Evangelist, Matt Formica. I want to welcome you to session 306, importing development projects for Xcode. You've heard a lot so far in the last few days about how to use Xcode and many of the new features of Xcode, but you may be sitting here today thinking that you've, realizing you've got a project in some other environment that you're wondering how you can get into Xcode in order to take advantage of some of the features that we've talked about. Or you may have a lot of experience with another development model and want to figure out how you can leverage your experience in Xcode to be more productive.

And that's what the goal of this session is. Here to talk to us about that today is actually Scott Tooker, currently the lead architect of Xcode's importing technology as well as other aspects of Xcode. He's a long-term, a long-time tools engineer at Apple. Since the dawn of Xcode. of Mac OS X. So here, please join me in welcoming Scott Tucker.

So one thing I wanted to make clear up front is in past years, we've talked a lot about importing from CodeWarrior, moving people from CodeWarrior to Xcode. And we thought, you know, this year, that's not the only message. Yes, we're going to talk today about moving from CodeWarrior to Xcode and the things you have to watch out for, but we're also going to talk about moving from Makefile-based projects, AMP-based projects, PbWo, even from Project Builder. So this isn't just about CodeWarrior anymore.

So what we'll cover today. For this session we're kind of assuming most of you have not used Xcode extensively or you've used it a little bit. But you're using other development environments mainly. So we're going to go over the basics of Xcode's project model and the build system.

Then we'll talk about importing your project and the different options that are available there. Then once you've imported your project, that's just kind of the first step. So we'll talk a little bit about moving to GCC and some of the pitfalls to avoid there. And then finally, what you can do in Xcode to not only make Xcode more familiar, but make your own workflow more powerful by leveraging some of its features.

So let's talk about the project model. The core of the project model is references and groups. References are used to point to files or folders on disk. You can use relative or absolute paths. And there are different relative path types available. For example, we have project relative or what we call the build product relative path, relative to where your build products are placed. And there are a number of others. And you can even define your own. And I'll get into that in a second.

We also have groups. Groups are very similar to Code Warrior's idea of groups, if you've used Code Warrior before. It's a hierarchy that's independent of the file system. What this means is that I can have a group, and it can point to a folder on disk. But it can also just be a totally logical construct.

This allows you to have organization within Xcode that's independent of your file structure. It gives you the freedom to organize your code how you want to see it in the project. Now I should note, Xcode, unlike some other systems, prefers explicit references to files that are used. So there's currently no support for recursive search paths. And we do prefer, as I said, that all files referenced, including header files, are in the project.

source trees. So this is something we added with Xcode 1.0, and what this allows you to do is define your own custom path types. So for example, I mentioned before we have project relative and we have build product relative. Well, we allow you to define your own absolute relative path types, and you can even reference other source trees.

The main place we see this being used is when you have a big bunch of code that's outside a project and it's shared among a number of different projects. For example, Power Plant is one example, or Qt. This technology is actually used by default by the Code Warrior importer. Whenever you import a project from Code Warrior, we automatically create a source tree that points to the MetroWorks Code Warrior directory, for example, to find Power Plant files.

So you've got all these files, you've got all these folders, that's great, but you want to do something with them. Well, that's where targets come in. Targets describe how to build products. They consist of file references and folder references in some cases, and a set of build settings. And then we take all this information, and most targets will use that to generate a product. Product is fairly simple. It's just an application, a static library, dynamic library, command line tool, bundle, et cetera.

Now, I want to talk a little bit-- jump back for a second. Now, I mentioned products. Well, it may turn out, especially in other environments, that you have your application split across a number of different projects. And you actually like this for a variety of reasons. We can actually support this in Xcode because we have what are called cross-project references.

This allows you to refer to targets and other projects for purposes of dependency analysis, but it also allows you to refer to the products that that project generates. So for example, if you have a bundle that needs to go into your app, but that bundle's created another project, you can actually bring in the project reference and then directly say, I want to take that bundle and put it in my application. This is also a technology that is used by the CodeWare importer, and I'll get more into that later.

So OK, so we've built something now. Well, now you want to run or debug it. So in order to manage kind of launch time information, settings and such, Xcode has what are called executables. These provide the ability, as I said, to run or debug products. They're automatically created for targets that create executables, like a command line tool or an application.

Users can also create custom executables. This is especially useful to run or debug executables outside the project. And where this really comes in to be really useful is let's say you're building a framework or a bundle, or you need to run some sort of test harness with your code, but it's outside the project. Well, for example, if you have the framework, then you can create a custom executable for the app that uses the framework and set it all up. And then within Xcode, you can launch your application, which is using your framework.

It also lets you set up multiple environments for an executable. For example, if you have a demo version of an app, maybe you want to set certain command line options to change how the app will behave. And you can have multiple executables so you can try the non-demo and the demo versions.

Finally, I'd like to talk a little bit about the project format. We get a number of questions about our project format. You know, can we read it? Can we munch it outside of Xcode? So to start with, we have a single file package per project. And just for quick review, a file package is basically a folder that looks like a file in the Finder. Inside this package, we have two pieces of information. We have the project-level data, which is stored in the project.pbxproj file. And that contains things that are common to--that will be seen by all users--references, products, targets, for example.

Then there are user-level data files. These are usually the username.pbxuser. These contain things that are only--that are per user and only seen by the individual user. For example, executables, bookmarks, breakpoints, UI configuration. And I should note, the project file and the user files are not meant to be hand-edited.

We encourage people to use Xcode or AppleScript to make changes. But I know someone will ask this, so I'll just get this out of the way right now. If you would like to see more of an XML-style format or whatever, I encourage you to file bugs, send messages to Xcode feedback to let us know how you want to be able to interact with the project file outside of the Xcode environment.

OK, so let's talk about the build system. Actually, this title's a little misleading, because there are actually three different build systems we have in Xcode. This is almost we're talking about the meta build system, because the three that we provide are, there's the Xcode build system, which we commonly call the native build system, the external build system, which allows you to access external build tools, and then the Project Builder build system, also commonly known as the Jam-based build system. And this comes from the old Project Builder, and it's there for legacy reasons. I'm going to mainly talk about the native system and a little bit about external build systems today. The choice of build system is the target level.

So what this means is you can have a native target, and then you can have an-- maybe you have a native target that builds your app, but you're using an open source library that you link in statically. And so you're using an external build system there, since they have a makefile.

And then for some reason, you also have maybe another target. Maybe you're doing something also with Java, and so you have another target that's using the Jam-based. The nice thing is that since this is at the target level, we have infrastructure outside of the targets that allows us to set up dependencies between these types. So you can mix and match the different targets.

OK, so let's talk a little bit more about products. We actually track two things in regards to products that you should know about. One is called the build products location, and the other is the intermediate's location. The build products location is basically when you build your app, this is where it's going to go. When you build your framework, this is where it's going to go. Intermediates are things like .o files, intermediate generated files, et cetera, going to the intermediate's location. These locations can be per user, per user, per project, or per user, per project, per build style.

But it's interesting, I didn't mention that they were shared. Well, the interesting thing here is that if you have a number of projects-- for example, Xcode consists of several different projects-- if you have all the projects point to the same build products location, we'll automatically pick up the version of, say, your framework that's next to your app.

What this allows you to do is I can make changes, for example, to the DevTools interface framework, and then run Xcode against it without having to actually go out and install the framework and try to get this test environment set up. It's just all from within Xcode, and it all just happens. So I strongly encourage people who have applications that are multiple pieces, where you have a framework and a dynamic library and application, to leverage this shared build location, because it's very useful.

So let's talk a little bit more about build settings. As you probably-- if you've been to the earlier sessions, they talked in much more depth than I'm going to today about build settings. But basically, build settings control the inner workings of a build. Do I want it to have debug symbols, optimization? Do I want warnings when I'm compiling, et cetera? However, we do have this idea of multiple levels of precedence for a build setting. And the higher levels are going to override the lower levels. And since it's so important-- we get so many questions about this, I thought it was worth going over again quickly.

So you may have seen this graph before. So at the lowest level, we have the environment variables. Things like $PATH, $HOME. These are things we get from the environment when we launch Xcode. And they're basically the lowest level setting. Over there are the built-in default settings. These are things that, at the target level in our code, we set. So for example, we decide that -OS is the default optimization.

Then there are the target settings. These are things that you are setting. So for example, you might go in and say, I don't want -OS. I want -03 by default for my target. Then there are build style settings. Build styles are kind of like-- if you imagine back in school, you had the transparencies where you could lay them on top of one another.

A build style is like a transparency. It lays on top of the target, and any settings you put in that build style override the target. So for example, we have a development build style. And one thing you'll want to do is you want to say, well, my development build style, I want to make there be no optimization or -0. And then finally, if you leverage Xcode build, our command line build tool, you can also set command lines-- you can set build settings at the command line that override everything.

So, overriding target settings. So, build styles, as I just said, were used to override target settings. One of the key things to remember here is we have the macro dollar paren value. And this isn't value you replace it with the name of the build setting. This is actually dollar paren value. And it's used to refer the setting value from the previous level.

And so now I want to show you a demo, if I can get the demo machine. One of the things we're commonly asked is, "Well, you know, I came from CodeWarrior, and I would like to put my debug in my demo one. Thank you." I'd like to put my release and my debug in different locations.

And in past releases, this has been actually not as easy as it should be. So here, let me resize this a little bit. I'm going to show you how you can easily set up though now with One Five and get not only your debug version and your optimized version in separate locations, you can also provide different names for each, and you can also do preprocessor macros for each. So the key here, as we said before, is the build style. So for example, here we're looking at-- we have two. We have development, which is debug, and deployment, release.

And so you'll notice here-- let me expand this out and see if I can get a little bit more. What I've done here is that we have this setting, the Development Build Products Path. This is basically the shared build products I was talking about earlier. And so what I've done is I've said, well, take the default value and add /Debug.

So I'm creating a debug folder in that general location. The other thing I've done is I've changed the product name. I've said, well, take the product name value and append debug to it. So in this case, we're looking at Sketch. It's a simple, small program. We'll get Sketch debug.

And then finally, I want to say, oh, well, you know, there's some debug code I want to run. So let's take the previous value of the preprocessor macros and append debug to it. And then in my deployment, I do the same type of thing. Except in this case, I don't have any preprocessor macros I want to set.

I just set the Development Build Products Path to have /Release, append release to the product name. And one thing I do here is that I turn off using the deployment location. Because in this case, I just want to have my optimized thing alongside my deployment. I don't want to create a root that I'm going to install later. So now there's one more thing. And this is what I actually discovered last night.

One of the problems you have is if you try to do this, just what we've done so far, is you'll find that you load the application, but it never fully loads. And I was like, why doesn't this work? Well, it turns out that the Info.plist for applications needs to be set up properly. And in 1.5, one cool thing you can do now is you can actually put in build settings in your Info.plist, and they'll get evaluated properly. So for example-- Thank you. I didn't do the work, but someone did, obviously. You can put in, for example, product name.

And the really cool thing is, is that it gives you what the build style will give you. I mean, it's -- everything's working the way it should. And so let me just -- I'm not going to build this here, but I just want to launch to just show you guys that, you know, this actually is real.

All I have to do -- I don't have to create -- oh, and the cool thing is, you used to have to create, you know, custom executables to manage all this. Mm-mm. All you need to do is just add the build style here, add these flags, and then, for example, if I build and go, and then you'll notice down here, sketch debug.

And so, for example, I put in some code on-- what was it?-- top edges. So you see here, I got this-- maybe a little harder to see, but I got this little NS log here-- ran align top edges. So let me terminate that. Go to deployment. And so here's Sketch release.

Well, let me try the same thing, just to show that it's actually, you know-- No log. So here we're showing you an easy way to have separate locations for your different variants of your targets. We're showing you how to have different names so you can easily tell from the docker, from the finder, which is which.

And finally, how to also set up the preprocessor macros, because many times, that's exactly what you want to do. Oh, one final thing I should show this to you. This is really cool, actually. I mentioned about the executable. It actually turns out that as I change this-- There's one bug right now, but if you reopen it, it will actually-- meh.

If you reopen it, it actually refreshes properly. So now you no longer need to. In one two, you had to set up your own custom executables. That no longer needs to happen. The only caveat currently, and this is stuff we'll work on for 2.0, is that our products currently don't automatically refresh when they should. And there are some issues around if you have multiple variants and you want to copy those products to other targets, we need to work through.

But for most of your usages, this should work fine. And unfortunately, I figured this out last night, so it's not in the image, but I'm going to work with Matthew Formica to get up some sort of tech note or example so that everyone can see how to do this. So there we go.

If we can go back to slides? OK. So we talked a lot about the native build system. Let's talk a little bit about our external build system. Our external build system support mainly comes through one thing, which is the external target target. It delegates build responsibilities to the external build system. So if you're using make, this means that make gets to run your build, that it's responsible for the dependencies, et cetera.

You can still use Xcode to edit your files. You can still use Xcode to-- I'll show later, to run, to debug. All this means is that the build portion is now being handled by someone else. You can also do the opposite thing. Let's say you just have some extra tools that you want to get into your process. You can use things like the shell script build phases and the copy files build phase to integrate these tools into Xcode.

There's also one that I forgot to mention on here. Anders would kill me. I forgot to mention build rules. This is another way that you can integrate external tools into your process. And I'd encourage you to go look back at the increasing productivity part two session, where we talk a lot about the build system and how to do exactly these things.

So now we've talked about the project model. We've talked about the build system. Let's talk about actually getting your project into Xcode. So there are a couple of different talks I'm going to cover here. First, we support bringing in Code Warrior Pro. We support bringing in Project Builder, Project Builder Woe.

And also, I put make file-based projects. Make files in quotes, because it's anything that's make-like, really, and even more than that. But the common ones are make, ant, jam, if you use it. But anything really that's on the command line, you access from the command line, you can make work. So Code Warrior Pro. Code Warrior Pro works with Code Warrior Pro 8.3 and 9.x.

It supports importing reference projects. It supports importing most Code Warrior target types that are relevant. So for example, we're not going to bother to import types that build 68k or build 68k CFM. What we do focus on is things like the Carbon. We will bring in Carbon CFM targets and just create the relevant Mako equivalent. We'll bring in the Mako targets, et cetera. The two noticeable omissions at this point are-- we'll bring in the res targets and Java targets.

Converted projects use the Xcode native build system. And the overall structure of the project is preserved. Although we will add some files, we won't remove any that are still relevant. Source code, however, across all of our importing, there's one key thing. Source code is not modified. This is not about locking you into Xcode.

This is about getting you over to Xcode and still being able to use your Code Warrior project at the same time so that you can make the transition more smoothly if you need to jump back. And new for 1.5 and later, you can now script importing projects in Apple Script, specifically Code Warrior.

So now what I'm going to show you is just a quick example of kind of a comparison between the CodeWarrior and the-- So here, let me do this. So if you can switch to demo. And one thing I'm going to do just to kind of show off another feature I'll talk about later is I'm going to use the condensed workspace.

So I've taken one of the CodeWarrior examples here, and let's just drag this down to CodeWarrior IDE. So, for example, this is PowerPaint. This is one of their PowerPlant examples. And so, you know, for those of you who use CodeWarrio, this is going to be boring. I'm sorry. But I just wanted to give a little bit of background here. So you notice they have files, you know, the files and folders, the files and -- let's find one. Yeah, so files, folders. Then you also have your targets. You have your link order.

And then for a given target, they have the active target there, you can have your settings. So just to give kind of a compare and contrast, just to show you what happens, this is an example of a project that's already been imported. So let me move actually this guy over here, and let's put him on files. So you notice that our condensed workspace looks amazingly similar to codeware.

But what I wanted to go over wasn't so much the look, but just what we actually bring in. So for example, you'll notice we keep pretty much the same structure. There are, though, a few important things to note. For example, we had this imported files group. And you'll notice, wow, there's a bunch of headers in there and various files.

As I said before, codeware uses recursive search paths. And they don't have you include headers, for example. Xcode really, really wants to have those headers in the project. And it works a lot better if they are. So when we do the import, the reason actually importing takes as long as it does is that we actually go through, scan your code, and figure out all the headers we need to bring in.

And so for example, we'll add just general ones in imported files. But for example, if I go to PP actions, you'll notice, well, here's a header file. How'd that get there? We'll actually look and see, well, if we find a header file, is there an associated C file already? If so, we put it in line with it.

Now here, if you go to the targets, you'll notice that I've created a PowerPaint PPC target. So this is just bringing it over. We do bring over some of the settings. I'm not going to go into details about which ones, but we bring over all the ones that are relevant to the project. However, we also provide defaults that are more appropriate for Xcode in some cases. And so here's your target.

And then we also, as I said before, an executable is automatically generated. Now, one thing is that you'll notice here, well, we don't have a link order. Well, so how do you manage link order? This is something that's asked from time to time. It actually turns out if I go open up the target in PowerPC, you actually can open up the sources phase.

And in here is your link order for all your C files. So you can just rearrange those, and those will rearrange the link order. And then finally, one thing that CodeWarrior doesn't have separately, I just wanted to quickly go over the-- is the executable. I just want to point out, you know, we have the executable here.

It's something I'm going to show more in the future demo. But just the idea that in CodeWarrio, you kind of look in one place, the target, to set all this stuff. Sometimes if you don't see something in the target, you might want to go look in the executable editor-- executable inspector to set some launch time properties.

And so that's that. So let's go back to the slides. Project Builder. It's kind of weird to talk about in this session because we actually don't do any importing of Project Builder. They just automatically convert as soon as you open. There's no import process at all. We just upgrade the project file, essentially. Targets continue to use the Jam-based build system. This makes it really easy. You don't have to worry about, oh, I've changed to Xcode and I've changed my build system. You can take it in tiny baby steps.

There are, though, very easy options to convert your targets to use native targets. And we can do this either for an individual target or the more recommended way these days, unless you have some Java targets, is just to do the whole project, since it will then do all the dependencies correctly. In either case, the original targets are currently preserved so that you can always fall back to the originals.

Project Builder Woe. Before Project Builder, there was Project Builder Woe. We still support importing most project types for Project Builder Woe. Most subprojects are now, as of 1.5, imported as native targets. However, WebObjects subprojects are still imported using Jam-based targets. As with all the other importers, project hierarchy is maintained.

External build system projects. So there's no direct importer. We get lots of requests, "Oh, can you make a makefile importer?" And then we think about going back to college, because that's where we'd have to be to make it, because it would take four or five years. But what we do allow for is, as I said before, we have the external target target. So what we encourage people to do is use the external target target to wrap your external build system.

If you don't desperately need it to be in Xcode, if you've got this makefile that people are supporting, like in an open source project, leverage the fact that we have this capability. So now, one thing I wanted to show is an Ant demo. So if we can come back, I'm going to show you how to quickly bring in an open source Ant project. And for this one, we will be starring the All-in-One Workspace.

So most people on the team know I'm somewhat of a gamer. I board game. I play games. I have video consoles, everything. So one of the things I've been doing lately is playing Diplomacy Online. So I pulled down this open source project that basically helps email players map out diplomacy. But you'll notice there's no Xcode project here. But there is an ant file. So what I can do is I can go to Xcode. I can say new project.

And new with 1.5, you notice we have some AMP-based templates. So I'm going to use the empty project. So let's see. I want to call it jdep. And then I need to choose a directory. So let me go to-- come on. Ooh, that's pretty. I like that. Let's try now. Now. OK. Interesting. Ah.

There we go. OK, so you'll notice, for example, in the Finder window, now I have this jdip.xcode file. So the empty project doesn't have much in it. So what I want to do is actually just bring in everything. So actually, in this particular case, I could just-- I could drag-- well, actually, I'll just drag it in. So let me just select everything. But I don't want you, and I don't want the build directory.

Quick tutorial on this. We get lots of questions about this. You'll notice this copy items just let you copy them into wherever your project file might be. In this case, I don't want to do that. The reference type and text encoding, for the most part, leave those alone. There are some known issues there, but in general, it does what you want if you're inside the project folder.

The one that we get a lot of questions on is this next one. It says recursively create groups, create folder references. The create groups means basically we create these groups that are logical and they might be tied to the file system, might not. Folder references basically say we're going to create a reference to the folder and then we'll dynamically track what's inside of it, but we won't create persistent references for what's inside of it.

In this case, I want groups, but there are cases like when you have a bunch of images or a hierarchy of resources you want just dumped into your bundle, it's sometimes better just to make a folder reference directly to the folder and copy that directly in because that way you can add references inside that hierarchy and you don't have to go edit the later.

So there we go. There's all my stuff. Now, it turns out that when I was looking at this-- let me just open up-- The default really isn't what I-- this is the one source code change I have to do to make this demo work. I was really bummed, because I was hoping I could do it without making any source code changes. But it turns out their default action isn't what I want. What I want to do is I want to generate a jar. So I'm going to use their dist option. So then let's-- oops.

So let's just scroll up. In fact, we can just close this all out, because I don't have to do any more source code changes. All I have to do--

And so there's nothing that needs to be changed here, but I do need to create a custom executable. If I can just remember-- there we go.

So what I'm going to call this one is I'm just going to call it JDIP. And it turns out what we want to do here, since it's just a JAR file, let's just do user-bin Java. So there we go. And so this is the executable inspector. You'll notice here I have my executable. It's user-bend Java. I can have some settings here. I also want to set a custom build directory, which is-- I believe it's a jar dist.

And then the other thing I can do is I can set up one argument here. And let's do -jar jdip.jar. Because it actually turns out that for whatever reason, JDIP has this nasty dependency on the common working directory. So I need to make sure my common working directory is set up. But that's pretty much all I need to set up. And so now if I go to, say, build and go, and let's bring up the build panel.

You notice I had it previously pre-built, and since Ant is kind of cool in that it notices this stuff and doesn't rebuild stuff, so now it's coming up. And we'll see if I remembered the correct path and everything. And there you go. Now we've got something up. And that was what, like five minutes, bringing a Java project.

And just to be clear, I mean, let me quit this. I haven't done-- I've done like five minutes. Let me go back to here. And if I was to go to say-- let me bring up the activity viewer. So you can see, OK, well, we're done indexing, but let's bring up the class browser.

Come on. Just like we've shown before, the index is populated. You're going to have access to all the Java information. All that's being done here is ANT is taking control of your builds. You're still going to be able to run it. You're still going to be able to debug it. It's a very quick way to get into Xcode very cheaply.

Why don't we go back to the slides? Oh, but Scott, you say, you don't have my IDE. I'm using Visual Studio. I'm using something. Something that's not here. Yeah, we can't do everything. We'd love to, but it just doesn't happen overnight. So the best thing to do at this point is do something similar to what I did with Ant.

It's create a new project, add new targets if needed, and drag in the relevant files, and just kind of go from there. If you can, using external build systems when you're dealing with some of these other IDEs, especially when they're make-based or make-like, is very powerful in the recommended way.

So you've got your project in there, especially if you move to something like CodeWarrio. Well, now you have to deal with a compiler change. You used to be using MWCC. Now you're using GCC. So let's talk a little bit about moving to GCC and some of the pitfalls you might encounter.

GCC has a different heritage than other compilers. It's open source for one. It's also been really focused on portability and compliance. GCC, in many cases, is stricter than other compilers, which makes sense, because of the compliance. And then one thing to note is when converting, you'll get a lot of errors.

You'll get, oh, my God, so many errors. But what you'll find out is that there are just a few common constructs, a few common patterns that you just need to tweak, and then a lot of them will just go away. I'm not saying there won't potentially be some nasty things you have to deal with, but for the most part, it's all very just simple changes.

So some of those simple changes. Let's talk a little bit. In the past, you'd do things like ifdef mworks to specify Mac OS X code. Don't do that. Use things like ifdef applecc or something more appropriate to specify the compiler you're working with. For example, use applecc when you're specifying GCC-only code. It's still appropriate to use mworks if you want to support both compiling with MetroWorks and compiling with GCC.

But to be clear, it's not appropriate to use that to indicate what platform you're on. This is kind of old hat, but don't include universal headers, things like MacWindows.h directly. Use framework includes instead. Trust me, the MacWindows.h on the system that's there for compatibility is just going to do the Carbon/Carbon.h anyway. So you're not saving yourself anything, including universal headers.

Don't assume that inlining works the same way between your compiler and GCC. Use things like -finline limit to set the maximum size of functions that will be inlined. This is very important. The inline rules are different, especially between CodeWarrio and GCC. Be aware of that. And we'll talk more about some documentation later that you can read through that talks about some of these things. Don't rely on #pragmasupport in GCC. Currently, it's just not there. There's some stuff, but not as much as, for example, what's in CodeWarrio. Try to use per build file settings instead where you can.

Don't rely on the size of Bool. Note that the size of Bool is four bytes on GCC, but one, for example, with CodeWarrior and Windows. So if you want to make truly portable code, don't rely on the fact that a Bool is only going to be one byte. Don't assume that true and one are the same value across compilers and defined statements. Use things like define foobar one and then if foobar to get the correct results across compilers.

We've got your project in. We've talked about GCC a little bit. Let's talk about how you can use Xcode now to make your experience with Xcode more familiar. But not only that, I'm going to also briefly kind of highlight the technologies that you can use to make yourself more powerful by using Xcode.

So making Xcode familiar. New for 2.0, workspaces. You saw all three different workspaces there. I would strongly encourage everyone here to take a spin with the developer preview for Tiger. Play with the workspaces. See which ones you like, which ones you don't. And for the ones that you like, if you see things that are missing that would make it just that much better, please file bugs. We do want to get feedback on these workspaces and make sure they're working for you.

So quickly, what workspaces are-- actually, can we come back to the demo machine for one second? For those of you who didn't go to the increasing productivity one, So we have the all-in-one workspace, which I showed before. And let me just-- I'll just use Sketch for all three. So what this does is allows you to have one window per project.

So, this is pretty simple. There are still going to be some separate global windows like the Activity Viewer, but pretty much when you're working your project, you'll be working in one window. And currently, for right now, you have to close projects when you change workspaces for the seed. But then I can switch to-- The condensed project workspace.

And let me open Sketch again. You'll notice this is much more compact. You'll notice that we have a much smaller project window. It doesn't have the attached detail view. It's designed more for those people who like to have lots and lots of windows and want their project window to not take up the whole screen, to be very small.

And then one of the things, too, on these is that we've also made things so the tabs actually will allow you to drag around. So for example, if you wanted to add this to a target, you can just drag things around, which makes this actually a pretty powerful view. And then finally, We have the old original workspace. So this is what we call the Xcode 1.2++. So, for example, you'll notice here we have a separate window for each task.

You'll also notice we've gone back to normal sliders. And then in certain cases, for example, when we bring up the find window, you'll notice now we have attached editors on most windows, so that when you do a find, you can just do inline -- you can do your -- you find replace inline without having to go between multiple windows. But otherwise, this is very similar to the Xcode 1.2 work style.

So that's the quick two-second version of WorkSpaces. I strongly encourage people to review the Increasing Productivity Part 1 session that was given on Wednesday. That will go into much more detail. So if we can go back to the slides real quick. So that's WorkSpaces. We also have key bindings since 1.0. We've supported key bindings for BBEdit, for MPW, CodeWarrior.

You can also create your own custom key bindings off of any of these. If there is an IDE that you would like to see us make key bindings for, please follow radars and let us know. External editors. Sometimes you just really, really like the editor you're working with, and you don't necessarily want to use the Xcode editor. So we have support for BBEdit, TextWrangler, SubEtherEdit, Emacs, and partial support for VI.

Just a clarification, unless you see the 2.0 bubble or the 1.5 bubble, this is stuff that already exists. Most of the stuff I talk about today is already existing. Finally, with text editing, I'm about to do a demo. I'm going to show you some text editing things. We get a lot of questions about, oh, I want to turn off line-wrapping or I want to turn off indentation. Where do I set all this stuff? I'm just going to do a quick tour to show you that stuff. Let's just go ahead and do the customizing Xcode demo. So if we can switch back real quick. So we'll use Sketch again.

So here we have Xcode. So let's-- oh, actually, I don't want Xcode. What I want is JDIP. So let's start out-- I talked a little about workspaces a little bit earlier. So next thing I want to talk about is the-- Let's just jump real quick. I'll just show the keybinds real quickly. Here's the keybindings. It's in the general preps. And as you'll notice up here, I'm using Xcode default.

But for example, we also have BBEdit compatible, MetroWorks compatible, and MPW compatible. You can also create your-- you can duplicate one of any of these and create your own custom keybinding set. This should just work as advertised. If it's not, please let us know. And also, like I said, if there are other sets you'd like to see, please let us know.

Some sets are harder than others. I should point out, for those people that are asking for Emacs, it actually turns out that Cocoa has a number of the basic Emacs key bindings already in place, in case you didn't know. But I understand there are more complex ones that you want.

So the next thing I want to talk about a little bit is file types. So we have this idea of file types in Xcode that allows us to say, oh, this is of a certain type. And those types can get pretty specific. So for example, if I want to, I can get down to this is documentation, or I can go all the way down and say, oh, this is a Java file, a res file, et cetera.

I just wanted to show real quickly, though, that our external editor support, the way it's set up-- for example, here you see, oh, it's currently bbedit, currently subethaedit. It's not just one editor you get to choose. You get to say on a per file type basis which editor you want to use.

So in this case, I like to use bbedit for HTML, but I want to use subethaedit to code with, so I can do some extreme coding with someone in New York. But just to show how this works, so for example, if I do Java, Then I can use sub-eth edit, but if I want to do HTML, it'll launch bbedit. There we go.

Yay. So anyway, this is just a really simple way. Like, if you really like BBEdit-- we know a lot of people love BBEdit. You can still use BBEdit. Go to town. It just works. It'll notice when you've changed files. It'll be able to open bookmarks, breakpoints, et cetera. It'll be able to open bookmarks to files. Clicking on Find Results should just work. It should all just work.

And this has been in actually since 1.0, although I believe Text Wrangler was added more recently. And then finally, I just want to talk briefly about text editing. So text editing is the main part to see all this stuff. And so for example, some of the common ones are oh, I want to wrap lines or not wrap lines. I want to show the column position, or I want to show my gutter, et cetera.

We also have a page guide, for example, if you like having a page guide at a certain number of columns, whether the editor uses tabs or not. And then indentation, here's our syntax aware indentation, and all the controls for that. And then finally, just to recap, for the code sense and the function pop up, that's all in navigation.

So let's go back to the slides. That's just kind of a quick-- those are some things that we find people, once they get those things changed, suddenly they go from being really angry to kind of happy. And then they eventually get to really happy when they get to this next part.

So, great. Now Xcode works more how you'd like it to work. You've got a nice work space you can deal with. You've made some changes to how we lay out files that you're happy with. But to take it to the next level, we've got a bunch of features in Xcode that will make you more productive. SDKs. Now you can develop for 10.4. You can develop for Tiger on 10.3. You can develop for 10.3 on Tiger. Fix and continue. Being able to edit your code and make changes while debugging.

Integrated documentation. We have great documentation support. I mean, it's awesome. You can get to almost anything in the ADC just directly from Xcode. And it's integrated even into your source code. So you double click on a symbol that's in Cocoa or Carbon or wherever, we'll take you right-- option double click, and we'll take you right to the documentation.

Distributed builds. Especially if you have a lot of machines, some of which aren't being used. This is a great way to utilize idle processor time to make your builds faster. Don't just use your own machine. Use everyone else's machine, too. SCM integration. Like we said earlier, we've added support for Subversion. So now we support CVS, Perforce, and Subversion. And they're all integrated the same way. You don't have different UIs for different systems.

Command Line Build Support. Xcode Build is a great way to do automated nightly builds or provide scripts that allow you to automate your process so you're not always having to sit in front of the IDE just to get a build out. And finally, Xcode is Apple Scriptable. It's not fully there, but we've added the beginning so you can do things like build, you can modify projects, you can look at properties. And we definitely would like feedback here. What's missing that you want? Because we want to make this really usable so that you can use it to make yourselves more productive and spend less time having to do these mundane tasks. So, in summary.

So in summary, moving your project to Xcode is easy. For many cases, it's automated. For example, Code Warrior, Project Builder, Project Builder Woe. Other projects need some more hand-holding. They may have to be imported manually. Make, Ant, Jam, and as we said, Visual Studio, other systems you may have to develop manually.

Be aware of compiler differences. I went over just some high-level items there. But what I found, I used to work on what's called the DTSWAT team, where we would help people move over from Code Warrior to Xcode, from Mac OS 9 to Mac OS X, et cetera. A lot of time was spent with the compiler. So don't just-- the import is the first step.

Respect the fact that you're going to be moving to a different compiler, and there may be differences. Even if you're already a Unix program, respect the fact that you are moving to a different platform. Don't just assume that it's all just going to come together. It's just all magically going to build.

And then finally, once you've gotten there, once you've got something that's building, Xcode is easy to leverage. You know, you have the flexibility to adjust Xcode to how you want to use it, but it also provides you the power to improve your existing workflow so that you can then go and make those Xcode -- you know, make those improvements so that you'll run even better on Mac OS X, so you can take advantage of things like AltaVec and Searchlight and WebKit, et cetera.

So some documentation, I mentioned earlier. The first thing obviously is Xcode help. It's right up in the Help menu. It's the first item, Xcode help. This will provide you documentation on how to use Xcode. That's the first place you should probably go when you have a question about how something works.

If you're moving from CodeWare to Xcode, we have some awesome documentation about moving from CodeWare to Xcode. It's in the installed Tiger docs on your system. Also, porting Linux applications to Mac OS X. And then finally, the Mac OS X technology overview. I strongly encourage everyone to read this. It contains a lot of basic information about how Mac OS X works. And you may think, oh, I don't need to understand that now.

But trust me, it'll go over things like file packages and all the basics, frameworks, and just give you a better feel for how things work, especially if you're new to the platform. So who to contact. If you have issues and you need to talk to someone, I encourage you to contact Matthew Formica, who is the Cocoa and Developer Tools Evangelist.