So what we're going to talk about today is the UNIX tools. There we go. Now, you've heard about Xcode and you've seen the demos, and Xcode is a full tool suite. Part of that means that it includes command-line tools. We have a full set of command-line tools of the traditional sort that the UNIX community is used to, has been using for a long time.

We use that to speed the ports. We use it to ease maintenance of the programs once ported. And what it really comes down to is that it's part of making Mac OS X a really superior home for UNIX applications. One of the best ways to characterize it is that things just work.

I have a number of acquaintances, including a number of the enthusiasts of that L system, and they would go to some trouble to run PowerPC Linux on their tie books, and they would run it for a while, depending on their level of dedication. But I've noticed that they tend to drift back to running OS X on them.

And basically what they've discovered, what they report, is that they can get their DVD player to work, the 3D graphics doesn't result in strange artifacts outside the boundaries of the X windows, and other things that will typically happen on a Linux system, even after this many years of development for it. So that's really the appeal of Mac OS X for a UNIX system. development.

So specific things that we'll talk about. We'll talk about specifically what tools are delivered. We'll talk about their unique features. We'll go into porting issues for bringing over new programs. And then we'll go into how to mix it up with Xcode. So you can have both a command-line environment and an IDE environment and have them work well together.

So Xcode. Xcode, Xcode, Xcode, Xcode. Yes, that's our big thing. But it includes command-line tools, and since, as the audience said, they're primarily UNIX people, that's what we're going to talk about. So what are their advantages? They're familiar. There's been 30 years of productivity on UNIX. The original UNIX designers were pretty smart guys. They understood about the composability of tools. And I throw out a specific example, and everybody snickers, but the UNIX guys knows that these kind of things come up on a daily basis.

And you take an example of, you have two files. You have, there's some references to a function that a bug report has mentioned. And you need to find the references, but these are very large files, and just grepping for throughout the entire files, there's too many of them. So you take a diff between two versions of the file, and then you grep that for these couple of function names.

And this is something that UNIX people do on a daily basis. It's almost a on-the-fly scripting kind of process. And it's very powerful. The UNIX world also, because of the time it's been around, has developed a large number of tools that are already out there, already in use. So we want to be able to take advantage of that very large body of tools.

told me these things were difficult. So the Terminal program is the basic way you get to it. And I'm not even going to ask. I'm sure everybody has used the Terminal program here. So the, but we have to show a screenshot for it, so I have to apologize for the graphics. The, because you have to get to the terminal program by clicking somewhere or another.

And so it's under Applications, Utilities, down near the bottom. The true terminal aficionado, though, puts his copy in the dock where it belongs. So the Terminal program, it opens up multiple windows. Each window runs a separate shell. And you have quite a few configurability options. You have a lot of the same kind of options you would see in something like an Xterm. You can set the character codes. You can set the colors of the screens. You can do all that kind of stuff. You also have some options that you won't necessarily see in an Xterm. For instance, you can set the transparency of the terminal windows.

And it's an interesting thing to see how that comes out style-wise, because some people, for instance, they find that very cluttered. And my personal terminal windows tend to be opaque. Other people, they like actually being able to see what's happening in the terminal windows that are both in front and in back. And so they'll set all the windows to about 50% transparency. And then you can see everything that's going on.

And then you just have the trick of figuring out which of the characters streaming by are from the front window and which ones are in the back window. So in Panther, we also include a server menu, which basically gives you shortcuts to the various SSHs and RSHs and so forth that you might want to do to run to other machines. So that's going to be a very handy feature.

Okay, so let us recite the catechism. So we say emacs foo.c. We cat it. This is our code review process. Being truly studly programmers, we don't bother with headers or declarations or any of that kind of stuff. We compile it with CC. We add a dash G because we like to debug. And we run it. We run .slash so that we pick up our A dot out, not somebody else's, like the virus. And it prints out hello. But we like the debugger a lot.

And so we're going to run the debugger on this anyway. And so we fire up the debugger with fire up GDB. We say break main. We run it. And we can step. And it still prints hello and all that kind of stuff. So we're actually done. I mean, this is everything you need to know for programming.

Nobody's getting up. Okay. Hear that? Everybody's falling asleep. I see a couple heads falling backwards already. I appreciate everybody coming out this early in the morning. I understand that it's a real sacrifice. Okay, for shells, we do offer a variety of shells. People use different shells because they have different scripting language, different usage characteristics. So for normal interactive usage, we have TCSH, Improved C-Shell. It has history and other good stuff in it. And we have also the ZSH, mostly because Jordan Hubbard likes it, I'm told.

And then we have the Bash, which is the GNU project's reimplementation of the Born shell, Bash being short for the Born-Again shell. So Bash also has the advantage that it's a fairly fast version of bin SH. Now for editors, we offer Emacs, the one true editor. And then we have the Emacs, the one true editor.

Emacs is highly customizable. It has its own programming language. It's probably the most widespread use of Lisp, perhaps even surpassing AutoCAD. And it's used for quite a lot of different things. People have built newsreaders and actually built IDs with Emacs. Quite a few different kinds of uses for the customization.

The Jaguar standard version is 21.1. The Panther standard version we expect to be 21.2. You can also get X11 and Carbon versions. The one that's built in a system is kind of a basic TTY-type Emacs, but we do have X11 and Carbon versions available as well. Now, because we value diversity, we also offer VI.

This is bad. I got a tough audience here. Okay. Well, I have a good story for VI then. And well, VI actually last regularly used VI just about 20 years ago. And I used it for about a year or so. And this is back in the days of BSD 4.1. Does anybody remember BSD 4.1? Yeah, okay.

It's very few clappings. Okay, well. It was a long time ago. Anyway, so I used VI for about a year and really never used it much after that. I went into a university environment, everybody used Emacs, and I kind of went along with the crowd and made the transition. But when I came back to Apple and VI would show up from time to time, like when you're checking into CVS. And after not using it for 20 years, I still remembered the commands.

I didn't know where they came from. I just typed the commands right away. So that's really a point in its favor. I'm not sure anybody would remember all the Emacs commands after that length of time. Now in Panther, we've upgraded to Vim, short for improved VI. It has more customization and configuration. And some people actually think it's too big, but that's OK.

Now we also have a number of other editors. We have Pico, we have Sed, we have Ed, and then for the real, real programmers, we have Cat. Now, how many people have actually written programs using just CAT? Uh-huh, yep. How many people have written a thousand-line program using CAT? Yeah, nobody's raising their hands now.

So for language options, we provide C, of course. We provide both C90 and C99. Some people call it C89, but that's wrong. It's actually C90. We do have C99. In Panther, we actually provide the library that goes with it, so you now have something resembling a complete C99 solution.

We have C++, we have Objective-C of course, and we have Objective-C++, which is essentially a combination. It's C++ extended with Objective-C features. We offer both 1.3 and 1.4 versions of Java. We also have an assortment of scripting languages. You get Perl, Tcl, PHP, Python, and Ruby. And so we also have third parties. We have things like MetroWorks, Absoft, NAG, and so forth.

You can also download additional languages, for instance, G77 for Fortran, Gnat for Ada. We got the Gnat guys here this time. There he is. OK, yes. We have these nutcases that have actually gotten Ada running on Mac OS X. It really works, and there's actually people doing useful work with it. We offer Lisp, or sorry, you can download Lisp and quite a variety of other languages.

So for build tools, there's basically three major options. GNU make is the standard. And it's just the standard, the usual GNU make. When you say make, that's the one you get. For people that need compatibility with BSD make, and you know who you are, we have BSD make.

We don't recommend it, however, for anything beyond what's required strictly for compatibility. Its features are somewhat different from what most people are used to. And then finally, we have PB build, which is used by Xcode projects. And it's essentially the command-line interface to Xcode. This is actually very useful in a mixed environment, because you can have somebody that works in the Xcode IDE, build up their project, add files, and so forth. And then if you, say, are SSH-ing in from somewhere else, you can type PB build and build the same project.

We, of course, have the usual collection of standard UNIX tools. The collection is most similar to what you'll find in FreeBSD. We have the CVS, RCS, SCCS, the trough and all of its little friends, the compiler generators, Bison and its friends, the various object tool working programs and programming tools in general. The total comes out to about 400 or so scattered across bin and user bin. Now, if that's not enough, we also have the Ports Manager.

And the Ports Manager basically allows you to add to the collection dynamically, not unlike software update. So the mechanism that we're currently using in Panther, or going to be using in Panther, is called Darwin Ports. And similar to the Fink and the FreeBSD Ports packages. In fact, just a couple days ago, we had a meeting with a company called Darwin Ports, and they were talking about how they could use the Fink and the FreeBSD Ports packages. And so the Fink and Darwin Ports guys have actually started talking about a way to integrate their two activities.

About 400 ports have been done in Darwin Ports to date, and it offers both command-line and GUI interfaces. So the command-line interface is port, and there's various commands, fetch, extract, etc. What it does, it downloads the sources, builds it, and installs it. So to actually get a look at how this works in practice, we have Sean Faegan, who's going to give a demo.

Hello, my name is Sean Faegan, and I do, as I tell people, I do UNIX-y stuff. All right, first I was just going to show you... Ah, wrong one. Thank you. I was going to show you the Ports Manager application, which is the GUI. And there it is. As you can see, I used the command-line to launch GUIs because I prefer the command-line.

The Ports Manager application is in Applications Utilities on Panther. And the first time you run it, it'll tell you it hasn't been installed. You want to install it. You, of course, say yes. It'll ask you for the admin password. And it'll download, build stuff, configure it. And then you end up with this. And here are all of the utilities, all the categories.

And as you can see, there are quite a few. Wow, there are. But I'm going to show you how to use the Ports Manager application. Again, I like the terminal. So I was going to show you a simple utility for all those people who need to speak Swedish.

Okay, I've already fetched it because the thousands of people using the network here, it gets kind of bogged down. So the next part is just to build it. Wow, that was easy. It was a fast machine. Next part is to install it. Also installed, rehash, because this is CSH. And there's the message of the day in Swedish. Wow, that was easy. The other thing I like about Darwin Ports is you can do this.

It has, by doing the package command, it has created an installable bundle. If I double-click it, it'll run the standard installation program. But it's already installed, so I won't do that now. The other thing I wanted to show you was one of the most useful aspects of the Darwin's port system is actually that you can use it not only to install tools and utilities and libraries and whatnot that you need, but you can also use it as a basis to figure out what to do for your own ports. And I had a couple of ports here. Let's see. Okay. Thank you. Huh. Come on. Display. Yes. How about Zap D-Vex? How's that? Yeah, yeah, yeah. How's that? Better? Bigger. 64.

Wow. OK. All right. It's actually very scary. So this is a port called OpenPSP. The port file, the file called port file, has everything about it in their description. And the part I wanted to show you was the stuff mark host configure. And that is a series of commands that are run after the configure stage in the process. And as you can see, this is an example. Someone had sharp pragma implementation in their source and you don't really want to have it. So that's an example of something you might need to do. It's very long.

The other example was... Let's see, I think this is eight. The other thing, in case it wasn't obvious from that, the Darwin ports, by default, install things in user D ports. And then for those of you who are familiar with the FreeBSD ports system, the structure will be very familiar, except that it uses a port file instead of a make file.

and here, all those configure args. I've actually run into a couple places where I needed to use the XPM library and I found that it was easiest to just grep through the port files in the Darwin ports to figure out the configure args I needed. And I wanted to show you one last thing. Editors. Okay. One thing that the port mechanism has that the FreeBSD ports mechanism doesn't have is variants. And they're marked by this variant command, as you can see in the middle of the screen there.

This one is how you would build the carbonized version of Emacs. And I had one thought about building it and running it off of my little USB keyfrog, which you can do, because it will actually build a bundle. But my little keyfrog is only 128 megabytes, and Emacs won't fit on it. There you go. Well, thanks, Sean. Oh, yeah. One last thing. There will be more discussion about Darwin ports at the open source session, which is session 102 at 1030.

Thanks, Sean. And I hope that some of you will actually volunteer to add more stuff to the Darwin ports. We have the next-- OK. So I'm going to shift gears a moment and talk about APIs. The fundamental API we have for OS X is POSIX. POSIX is-- we don't have a total, complete, every last detail passes the conformance test POSIX. What we do have is essentially as much POSIX as just about everybody cares about. So if you find anything that's not conformant, and we want to hear about that because that means there's at least one person that cares about that little bit of POSIX.

We also have OpenGL and GLUT for interface. We have Carbon and Cocoa for GUIs, which there's a number of sessions going into the details of those APIs. For doing drivers and kernel extensions, we have something called I/O Kit. Unfortunately, if this is new to you, you're out of luck because the I/O Kit session was yesterday. But you can certainly find out about it in online documentation and so forth.

And I/O Kit is interesting because it's a C++ framework that allows you to write drivers without actually recreating everything that is required for a driver. It uses inheritance. And if you've ever tried to write a Linux device driver or just read the book on Linux device drivers, you can appreciate how much of an advantage that is. We, uh, Panther X11 is integrated with the system. So, yeah.

It is one of the big demanded features from Jaguar, so that's good to have. We also provide IPv6 via the CF network API, and this is such an important API that it actually has its own session on Friday. So if you're interested in that, go for the session.

For some more details about specific API things that are new in Panther, we have pull, we have dlopen, Oh, come on. This is another one of the most requested features from Jaguar. Yes, deal open and it's friends. We also have a number of new libraries, libxml, we have the wide care library for C99 that I referred to. We have a couple of libraries for internationalization as well. Again, in general, the API will resemble what you see in FreeBSD 5.0.

I have to talk a little bit about frameworks because that's something that is unique to OS X. And a framework is essentially a shared library. We'll often use the term "dilib" to refer to the single file that is the shared library proper. But the way a framework is structured is that it packages up the dilib and the resources and the headers all into a single place.

And this is basically a little bit more sophisticated design than you'll see in something like a standard UNIX-type system, where the resources are who knows where and the headers are mooshed into use or include along with everything else. So the framework packages it all up, gives it a place, as you can see down at the bottom of the example, where you can essentially have separate files for each language that you wish to translate the strings that are used in that framework.

Now, to use the frameworks, you just say include foo/foo.h for a framework named Foo. To link it, you add a dash framework and then the name of the framework. Most of the supplied frameworks you'll find in /systems/library/frameworks. And if you look in there, there's 40, 50, 60. There's actually quite a few. QuickTime is a framework. The whole of Carbon is a single framework and so forth.

Now, if you want to add your own frameworks, you can drop them into System Library Frameworks, or you can put them in your own place and then direct the compiler to find them using -F. And this is, again, an option that is unique to Apple's version of the compiler. And it works a lot like -I for adding a place for finding include files.

Now, the traditional UNIX-y type headers still live in user include. So you'll see that sometimes it's a little bit of a confusing situation because we'll talk about a system framework. And system framework is essentially our term for what would be called libc in Linux land. But the headers are still kept in user include because if they were actually under system library frameworks, no one would ever be able to find them.

So the most important thing to know about the compiler is the compiler is gcc. I think everybody knows that by now. A couple of years ago, this was a little bit more of a less well-known. So all the usual gcc options work. Now, we also have a number of additional compiler options, and there's actually a whole session that goes into detail on this. There's a couple that are especially interesting for UNIX porting.

One of them is -f-altevec, which enables Altevec types and built-in functions. It is more powerful and slightly different in behavior than the -m-altevec that is an FSF gcc. The details are more complicated that I can get into here. Find me afterwards if you want to talk about it in depth.

We also have an option that's called -mdynamicnopic that's recommended for applications. The normal mode of code generation for gcc is to generate relocatable code. That is, by default, everything you build can go into a shared library that can be relocated around the memory space. But the code for this is not quite as efficient as it could be, and so for an application which is not going to be relocated, you can say -mdynamicnopic, get a little bit more efficient code, but at the same time still get to relocatable dilibs.

Now to build libraries, you have the traditional mechanism to build a libfoo.a, you use ar to build the library, you use ranlib to build the table of contents. This is a little bit different than ELF. In ELF, you don't need to run the ranlib step, and so sometimes programs that you're porting over won't actually arrange for the ranlib step, and you have to add that yourself.

To build the dynamic library, use cc-dynamiclib. Now, most of the time, you won't actually need to supply that argument yourself, because if you use lib tool, lib tool already knows about all this, and the versions of lib tool that are out in the world already have the necessary OS X support. It's possible that you'll run into an older program that has an older copy of lib tool that's been sucked into it. In those cases, you'll need to update the lib tool in the package.

So to keep track of versions, there's really two layers of the system. The lower layer system, we call Darwin, consists of the open source code. There's no framework. The framework support is there, but there's no frameworks that are normally shipped with as part of Darwin. There's also no GUI, so Darwin is a real bare-bones UNIX system.

The tool software version, swvers, reports the OS X version, and that's going to be a 10.2.6 or 10.3 or what have you. The uname-a, another UNIX command, reports the Darwin version, which looks a little bit different. And it's changed somewhat since 10.0, and so I provide here a handy little chart of exactly what happened to it. So the main thing to keep in mind is that a 10.x, you add 4 and you get the Darwin. the major Darwin version number.

Okay, yeah, so the most unusual thing about this is that the Darwin numbering scheme changed partway through 10.1. So I see that 10.10 is 1.4, and then we change it to be a more consistent numbering scheme. And, well, I won't explain why it's more consistent, it just is. and David It corresponds, if you see, if you look in the About box in OS X, you'll see down the bottom it says a number like 7A179. And the 7 is actually where the Darwin version number comes from. So it ties into parts of Apple's internal process.

Now, most of the time, programs these days-- or I should say most of the time, but a large number of programs these days use GNU Configure and Make. And those programs will almost always just work. Once in a while-- this actually was more true last year than it was this year-- the config.guess and config.subscripts, which essentially tell you what kind of machine you're on, they needed to be updated. That's much less commonly true nowadays.

Now, we do recommend that if you have to have some kind of test for system-specific features, that don't try to rely on the predefined macros. We have those. There's a double underscore Apple. There is a double underscore Apple CC for compiler version. There's a double underscore Mach and so forth. In practice, it's hard to come up with exactly the right combination of those that refers to a specific version of Mac OS X.

So, in general, we want you to look at features, test for features instead. And if you want to actually set up a whole bunch of code that's ifdef for OS X specifically, define your own preprocessor flag, Mac OS X, and set that up with a dash D in the make file. And so, a configure script adds the dash D Mac OS X, and then your code tests ifdef Mac OS X. That basically gives you more control. And it also means you're not as subject to minor changes that might happen from one compiler or one OS revision to the next.

Now, porting an interface, despite the command-line focus, we know that there's quite a few little GUIs of one sort or another on UNIX tools. Curses just works. We use the nCurses library. It's very standard. If you link against that, unlikely you'll run into any difficulties. We have versions of TickleTK and QtMac that are adapted for Aqua. And you, in fact, saw a demo of QtMac yesterday with the spinning gears and all.

X11 just works. X11 applications will actually auto-launch the server, so users may not even be aware that they are running an X server behind the scenes. OpenGL and GLUT are standard libraries. You will have to translate any includes of GL.h. OpenGL and GLUT are standard libraries. You will have to translate any includes of GL.h.

So just briefly to go over some of the common problems that people run into. The first is the CPP precomp. Now, CPP precomp has gone from 3.3, so this is as much historical as anything else. The 3.1 compiler would use CPP precomp, which is very useful for things like Cocoa, but UNIX ports generally don't have large enough headers, or they don't use large enough headers to actually need precompiled headers. So it's kind of a waste of time, and CPP precomp does have some areas where it wasn't entirely consistent with the normal GNU preprocessor. And so the usual advice is to add a no-CPP precomp. It's still good advice, 3.3 will just ignore the no-CPP precomp.

There are some missing declarations and functions, although last year there was a bunch of easy examples to point to, but all the ones I knew of have been fixed for Panther, so there's nothing to point to anymore. But I'm sure there's still some that are out there. You may also run into duplicate definitions.

That is, the system framework will have things like getopt will be compiled into it, and your program may also link in getopt, its own version of getopt, and then you'll get complaints. Now, on a Linux system, it will just note that there is a duplicate definition and will go on. And the OS X linker will actually complain. It will say, oh, multiply defined, you know, this is an error.

And we do this because this ties back into the Mac world where multiple definitions of symbols were hard errors. So the way to deal with this is to add a dash multiply defined suppress. And this is something that's a linker option, but you can hand it in this form to the compiler.

told me this was a squirrel-y. So other less common problems you might run into, pthread functionality. Some pthread functionality is missing even in Panther. You can run into namespace conflicts. And this has always been a concern. Although in practice, it doesn't seem to happen that often. And there's an option called two-level namespace, which is way too complicated to go into here. Just read the linker man page, and it has all the gory details.

As I mentioned earlier, this actually happens a fair amount, so it's really not a less common problem, is to remember to run ranlib. That's pretty straightforward. You just have to remember to do it or add it into the make file. Another thing that a few people have bumped into is that the NCURS is a separate library in Jaguar and later, and previously it was included in the system framework. And so basically if you want a program that will run in both pre-Jaguar and post-Jaguar systems, you'll have to build them slightly differently because the library is no longer being incorporated as part of the system framework.

Now, most of the time for porting, you want to use AutoConf. AutoConf is normally automatically used in GNU-type configure scripts. And it's really the best way to test for OS features on the machine that you're building on. And it basically the process, actually I should ask, how many people are not familiar with AutoConf? Okay.

Basically, Autoconf is horrible, horrible mishmash of scripts and macros and various kinds of trickery. The basic concept of Autoconf is pretty simple, though. It will build a tiny program. For instance, a tiny program that includes a UNIX.h, which is a non-standard header. And it will compile the small program, and it will see if it errors out.

If it errors out, it says, no, UNIX.h not found, then it sets a macro. It's a macro called haveUNIX.h, and then is zero. So it says that this header has not been found. And then you can use that in your sources. If haveUNIX.h, then include UNIX.h, otherwise don't include it. So it's a very powerful mechanism, and this is really the core of how a lot of these programs can be brought to a new system and just build the first time.

And we're lucky in that there's actually a book now in AutoConf describing it in great detail, written by the people that put a lot of it together. But it has one fatal flaw, which is that it tests the features of the machine you're building on. So if you're running Jaguar and you want to build for Panther, or as I'm sure everybody's doing now, I saw installations going on all day yesterday, everybody's running Panther, and they want to build for Jaguar, AutoConf won't do the right thing. It'll build a program that'll work just fine for Panther and may or may not work on Jaguar.

So we provide an availability macros.h, and it's under user include. And what this will do, this will actually have a set of flags, a set of definitions, that are used in the OS X headers to say whether a particular feature is available in Jaguar, Panther, what have you. And so you actually want to make those tests when you're using features that are not available in all versions of OS X.

So going to a few more caveats. Don't abuse root. It's a personal machine, sure. Why not step on stuff in user bin? Improve the compiler. Overwrite the headers. We really don't recommend this because you can easily get into a situation where the program builds on your machine and doesn't build on the machine of the person next to you.

In fact, I ran into this just yesterday because I had some header files that I had not moved forward to a new installation. So be careful about this kind of thing. Use your local. We have a full set of user local. We keep our own hands off it so that you can fill it up with your own things.

The Maco object file format is actually a very different file format from Aout or Elf or any other format. One of the consequences is no standard GNU binutils port. I often hear people say, well, the first thing I need to do is build binutils on OS X, and then I can continue with my work. I say, well, that's not going to get you very far. So if there's anybody that wants to port binutils to Mac OS, please see me afterwards.

So another thing to watch out for is whitespace and path names. You get a standard installation, you have a /Macintosh space HD. And if you forget to properly quote your file names, bad things can happen. In fact, some of you may remember there was a bad thing that happened in something in an Apple tool where somebody forgot the quoting.

So beware. Another thing that happens, at least as often, is HFS versus UFS issues. Foo.c, Foo.bigc, CamelCapsFoo, all these things are turned into the same file. And this has some interesting and unfortunate consequences. For instance, if somebody has a CVS repository with files of the same name differing only in case, and CVS just does not like that at all. Every time you do a checkout, every time you do an update, it says, oh, this file already exists. I've already checked out this file. And it tries to overwrite it with the other file anyway. Very confused situation.

Another consequence that I believe Sean pointed out to me that I hadn't heard of before, a lot of times people will have a file named install in all uppercase. It's like they're reading me about how to install. But they also have a make install action. Well, on a UFS system, make install will say, oh, the install file's there.

It's perfectly finished and done. There's nothing to do. So make install has no effect. Stan Shebs, Sean Eric Fagan, Bodhi Gerfen Okay, a couple words about the debugger. There's a whole session on debugging later on, so for the gory details. Mac OS X debugger is GDB, currently based on the 5.3 release of GDB from the FSF.

It has a large number of extensions. There's some Objective-C stuff. Objective-C stuff is going in FSF GDB, but it's not all there yet. So we also have Mach support, we have framework support, we have a number of additional commands. Again, some of these are making it into FSF GDB, but they're not all there yet.

Now, again, there's another session with all the details on gcc, so I'll just hit the highlights. The Jaguar system compiler is 3.1. We still have 2.9.5.2, and this is used for compatibility with 10.1, in particular, if you're building KEXTs. 10.1 earlier cannot run a 3.x compiled KEXT, although the reverse is true.

The Panther compiler is 3.3. And so it's already sitting on your systems. As I think Ted mentioned yesterday, even though the Xcode is still in preview state, the 3.3 compiler is a GM compiler. We've used it for quite a lot of stuff, and in general, it's been of pretty good quality.

Special features of 3.3, we have even more optimization. You saw the spec numbers are getting better all the time. We get even better C++ conformant. We have a new mechanism called PCH for precompiled headers. So CPPrecomp is gone. PFE is gone. PCH is the only way to go.

So how do you deal with all these different GCC versions? Well, we give them all different names. So 295 compiler is always a user bin GC2. The standard version 3, whatever standard is appropriate for the system, is at gcc3. And then we symlink cc and gcc to one or the other of these.

To flip back and forth, if you want to, it's very often convenient just to change the default so that the makefiles and so on don't have to know about this distinction. You can use the script gccselect, which is also unique to OS X. And it's basically an elaborate script that will choose the compiler that is the default compiler. It knows about setting up the auxiliary programs, the headers, and all that stuff. Since it's actually affecting user bin, you do need to be root to run it.

Yeah, okay. So I press it harder, it makes it work better. Okay, now Bodhi Gerfen will come up and give us a little demo of using the Xcode IDE with open source projects using two different modes. Cool. Thank you very much, Stan. I'm afraid of this thing now. Well, good morning. How many of you guys yesterday went to the Developer Tools overview session? Just want to get an idea. OK. Great.

Well, this morning I want to look at three different things related to our Xcode product. I want to look at two ways that you can take your existing open source applications and bring them into the IDE. I want to look at some benefits of each of these two ways. And most importantly, I want to give you a couple of examples because I want to show you what steps you can take as a UNIX Developer, as an open source developer, to actually start taking advantage of these -- of the IDE.

So to begin with, two types of integration into the IDE. The first type is you can keep your existing make file. You can keep your make-based build system. You may have seen yesterday where Tony TV got on stage and talked about all the benefits of the dependency checking that the Xcode IDE provides. But if you already have a project based on make, perhaps you're doing -- you're working on an open source project with another group of people, you don't want to lose all the work you've put into it. You can continue to do that.

Our IDE will not change your files. It will support your make files, and it just -- it adds another file in the directory that allows the IDE to keep track of files. The other thing you can do is you can use Xcode's native build system. And this is going to mean going through the Xcode IDE, you're going going through perhaps your Makefile today, figuring out your targets, figuring out some of the settings, and changing settings in Xcode. So we're going to look at some examples of each of these.

So to begin with, the benefits of keeping your existing Makefile and using it inside the Xcode IDE. Well, obviously the big benefit is you already have it, it's probably already working. But why would you want to bring it into the IDE? Well, there are some benefits. You get a graphical IDE. You get one of the really nice features that Stan pointed out to me that he likes is the symbol indexing that you get through the IDE.

We have a nice batch find. We have source control integration. And of course the documentation is there, both API reference and conceptual docs. And we didn't forget about your man pages. Since you're coming into the IDE, we still let you view the man pages through that. He's Mr. Man Pages. I like the man pages. I spend a lot of time in them. And I don't like Rof. He bugs me every time I don't write one. Exactly.

So to begin with, we're going to look at a demo of using an existing open source project that's Make based. And I'm going to show you how to bring it into the Xcode IDE. Just some simple steps. Obviously, things are going to vary a little bit. But to begin with, I always got to start the app, which I was smart enough to have running already. In Xcode, just choose new project. And in this case, we're using a Makefile, so we're just going to choose an empty project. And I'm going to call this one -- I picked something nice and big here. Subversion. And I've got it here in my examples source.

So you need to set a directory. If you're bringing an existing project in, it's probably good to go, just like I did, go a directory up. So my source code actually is in-- I'll show you where it is-- in examples, source. There's my source code. So I chose the source directory and then named the project Subversion, the same project name as my existing project that works with Make.

So when you do this, you just get-- we chose an empty project, so we get pretty much an empty project window. First thing you want to do is let's bring in our source code files. So under the Project menu, we're going to Add Files. And again, I navigate to where my source files are. Got to go with column view. That's much better. All right.

So I'm going to add these files in here. It's going to take a little minute. First, we need to choose-- take the default options. You do want to create groups for any added folders. This will let the Xcode IDE go through all your source files, add it to the index, let you find all the symbols.

We've got to wait a second here. And boom, we've got all our files. Now, you saw some of these things yesterday, and I encourage you to go to the later sessions on the Xcode IDE, but you get a lot of benefits. So I'm not going to go into a lot of detail on all the benefits you get. I'm just trying to give you a starting ground for your projects.

But you notice we have, we can now search on, we can choose the project here and search, and we get the nice fast find. We can go through everything. We also get the more enhanced find where we could look for, I don't know, main, and we'll get down here under the find results, we see all the occurrences of main in all our files.

So you get a lot of benefits there. We also have, let's stop that find. Thank you. I mentioned the symbol lookup, which is another nice feature. So let's look in here under Subversion. It's a nice management system also, you can see. Clients, command-line, I don't know, let's take, for example, main.

Notice this pop-up right here. Excuse me. It collects the symbols in that particular file, so you can do a nice quick jump to get to the various symbols in your file. We also have the documentation lookup. I mentioned the man pages and the regular documentation window. So you get a lot of benefits, and you haven't changed anything. You haven't changed. All you've done is you've added in your source file.

All that we've done is we've added this pbproj right there. The rest of the things are just the same. So if you have a group of people that some people want to use the IDE, some people want to use command-line, it's okay. And at Apple, we do that.

Our engineers are all over the map. Some like the IDE, some like the command-line. That's the beauty of it. So you can see here some basic benefits you get. I guess I should show you it building to prove that it actually builds. Oh, yeah, because we forgot an important step here.

In our project, we've got the files in. The one thing we have to do to actually build it is add a new target. And in this case, we chose new target from the project menu, and we're going to choose the appropriate name, GNU make target. And I'm going to call it something obvious like make. Finish. And let's see if this actually works. I'm going to open the build window so you can see what's going on behind the scenes here.

I think I touched a file in there. Most of them are good. Oh, we have one file I touched. And so make goes ahead and redoes it. And we were successful. So very minimal work to bring your projects in. That was-- yeah. You saw it's pretty trivial. All you need to do is make a new project.

An empty project is the best. Then you need to add your files in, and then just add a new target, a GNU make target. So if we can go back to the slides. So that's using an existing build style, a make file, with the Xcode IDE. But what if you want to use the native build system? Maybe you sat in a couple sessions yesterday, the keynote, the development tools overview, and you saw all those great features.

Their list was a lot bigger than that list. Their list was more like this list. What if you want to take advantage of the zero link, the predictive compilation, the distributed build system, the code sense? There's a lot of great features they showed you. Now some of those features are dependent on gcc 3.3, but all of them are dependent on the native build system of Xcode. So what if you want to take advantage of those? So again, a quick example of that.

And if we go back to the demo machine. Thanks. So in this case, I chose a much simpler project because it's a pretty dang big project there. We've got this little command-line tool called RMAN, and this is actually the tool we use inside Xcode to generate the HTML man pages. It's a very simple tool. We only require one file to actually build it. So take the examples here.

I understand your projects are probably going to be a little more complex. Again, we're going to start with a new project. This time we're going to do something a little different, though. We know what we want to end up with. We know we want to end up with a command-line tool.

So I'm going to choose standard tool. And same thing again. RMAN. Actually, that file is already okay. But I'm going to choose the directory where my project exists. I'm going to give it the same name, RMAN. And you can see there, volumes of sample source, RMAN. Oh, template files already exist.

You always got to have something fun in a demo. All right, so we end up with a project here. Now, this one's a little different than the other project. The other one was an empty project. This one-- will actually-- let me debug show run log. This one actually does something if we build it.

Excuse me. This one, if we build it and run it, it's a simple hello world application. Now, this isn't the application we wanted, though. This is just a template file. When you use one of the template files in the Xcode IDE, it sticks a couple of basic files in there, usually a header file, a source file, maybe a man page in this case, since it was a command-line tool. And it also sets your build settings for you.

It sets linker settings. It sets the basic things you need for that type of project. So first thing we've got to do in this one is I'm going to show the target pane here. And I'm going to remove this main.c, because that's not the file I want. So I'm just going to uncheck it, which removes it from this target. And I'm going to drag in the file I want, so our man.c.

Of course, you could do it like we did before, go to the project menu and add files, but, you know, it is a Macintosh. Drag and drop works. So we've added our source file, and things should just work. Oh, but life's not that good. So if you look here, this is one of the features you get by using a native target. You get the integrated error and warning reporting. So over here on the left, you can see-- I guess I'm pointing to the screen, which you guys can't see. Over there on the left, you can see the errors and warnings.

And you notice we have a couple of errors. We have, what, five errors, and we have a bunch of warnings. We're not going to worry about the warnings right now, because at least we can get it to compile. But what about those errors? This is the kind of thing you're going to find if you're importing your project into the Xcode IDE. You'll notice our errors are all about variables that are defined. And if you look at it, if you look in your source project, I notice that a lot of these things are defined in my make file.

So for example, we've got vol list. And this is the call-in. Excuse me, let me make this bigger. I realize you can't see it back there. If I look in my Makefile and do a find. I can see that, yeah, indeed, they did set this variable in the make file.

So how do you get these kind of things into the Xcode IDE? This is a very important thing, and this will help you get your projects into the IDE. So we notice that there's a lot of things defined in the make file. All you need to do-- let's go back to our source code.

All you need to do is go to this Targets tab here, choose the target. When we made the template, it automatically added a target, a command-line target. One of the features in Xcode is, the IDE, is that it uses the inspector a lot for a lot of your build settings. So we selected the target, and we're going to open the inspector, take a look at it, and we see general settings, build settings, some rules, properties.

Well, this is a variable we want to pass in, so under the build settings, we're going to look at our current settings. I'm going to open this drawer and look at our current settings, and here you see a nice, Nice thing that you might be familiar with. We've got other C flags. So in this case, I could add in minus d, and whatever that setting was, or minus, there we go. And then over here I could maybe add a new variable definition.

Again, we open, we look at the target, we open the inspector, we look, I'm going to look in current settings. If you want more details about all these different things in this drawer here, the help has some information on it and also the sessions later on give you more details. But if you look here, I've set in the options that I needed, having looked at the make file, I've added in some variable definitions, and let's see if this just works now. So we'll show the build log, because that's slightly interesting.

And this is actually a nice feature here. This button right here allows you to see what's going on. We're not doing any magic here. We're still running the same compiler that Stan talked about earlier. This lets you see what's going on behind the scenes. So if we build this guy-- ooh, build succeeded. Beautiful.

So all I did was added in those settings that I looked at in the make file. And again, you can take a look at it in the main project window. And you can see here's our existing errors. We no longer have any actual errors. We've just got some warnings. We can cruise around, find things quickly. So back to slides, please.

You can see that there's a lot of benefits you can get by using Xcode's native build system. You saw how easy it was to bring your existing Make files into Xcode and acquire some of the benefits there. So I hope this gives you something to hang on to as you go into the other sessions and see and realize that as a UNIX developer, as an open source developer, you can take advantage of our great Xcode IDE. So thanks very much.

One of the things that should give you confidence about the mixed Xcode and the command-line setup is that actually this is what Apple uses itself to build OS X. OS X consists of some 1,200, 1,300 projects, of which the kernel is just one. And it uses the, many of the projects are set up to be Xcode projects, but the mass build, that is the final build of the entire system, is done with one very, very large script that does a command-line invocation of these projects over and over. So another case where we do, in fact, eat our own dog food.

Long time. No, we actually have build fleets, as they're called, of several machines ranging 8 to 20 machines. Just depends on which group is doing what kind of build. Yeah, so it's all distributed around. It is enough code. I estimated one time I sort of did a "back of the envelope" kind of thing. I came up with some 30 million lines of code in the system as a whole.

Don't quote me on that. That was just my personal estimate. So it was enough code that sometimes the machines actually will be hit by alpha particles or something like that in interesting situations. Anyway, so not to digress. To instead to sum up, as you see, Xcode is a complete tool environment. Part of being complete is including a full set of command line tools. We have quite a few command line tools. We have a set of various levels of power, shall we say.

The standard porting techniques are sufficient to resolve the API differences they are. We have a Darwin port system that will ease the transition. You can either download the tools. The other thing that we didn't really go into any depth is that you can also look to see how people have done Darwin ports to see how other people have solved the kinds of problems you might run into. And finally, we've seen how you can actually use both the Xcode IDE and you can use the command-line tools, and they actually interoperate in a useful way.

So that's the content. For more information, We have a number of things online. We have the UNIX porting guides about porting the package UNIX software, details of the compiler, debugging, assembler, and so forth. We have a Maco runtime architecture book that's interesting for the true nerds. We also have a technical note on the porting of command-line tools, which says a lot of things that I've been saying, so if you'd like to see it in printed form. And I mentioned getting config.yes and config.sub if you need to, and this is the URL that actually takes you there to get the latest copies.

So, additional, we have some URLs to pick up stuff, both the official Apple site, developer.apple.com, and the Darwin pages. We also have opendarwin.org, which is where the Darwin ports come from, and then Fink, which is a source forge. And then finally we have our contact addresses. We have Xcode feedback.

We have a large collection of mailing lists. I'm on way too many of them myself. So if you want to get a hold of me personally, that's one way to do it. And then, of course, Godfrey likes to put his email address. And he loves getting email. So send him lots. Okay, well, that's it for me. Thank you very much.