WWDC2003 Session 307

Transcript

Kind: captions Language: en morning everybody this is session 3 07 Apple tools for carbon development I'm Chris Espinosa I've been with the development tools team working on xcode specifically for the last six months or so I've been working with development tools in specifics in 93 i guess and i've been working at apple since the Carter Administration there we go trying to figure out where to point my clicker it doesn't point there we go okay what we're going to cover this morning is an overview of Apple tools you've probably seen three or four these overviews of Apple tools but we're going to do it from a carbon perspective this morning we're only going to be talking about carbon applications the process of bringing a project whether it be a project builder project or a code warrior project into Xcode getting your code to build with the xcode ide and with the GCC compiler some hints and tips for optimizing the build time and the turnaround time how you can take advantage of the xcode features a little bit about xcode support for mac resources if you have resource-based carbon projects which most of you do and just a little bit about designing carbon interfaces with interface builder there are other sessions on interface builder and there's a really great session on building a modern Mac application which recovered using nibs in your face builders later on that I'll point you to but I'm just going to do a brief overview of that now I want to do the standard disclaimer here I am talking about Xcode and I'm talking about carbon the fact that i'm talking about those two things does not mean that we are killing everything else that I'm not talking about we are not killing cocoa development we are not killing Objective C we are not killing applescript we're not killing java or eof or anything like that the fact that I failed to talk about something does not signal it's imminent demise I just want to make that clear so the tools you've already seen in a couple of sessions the Xcode integrated development environment and you've seen a lot of the great features of that the code sense feature the great indexing the great work flow and navigation it's a project manager and build system it's got a integrated code editor and an integrated debugger the debugger i'm going to show you tomorrow we're just going to build today interface builder is another key tool it's primarily a cocoa development tool but we are moving more and more to using interface builder as the principal design tool for carbon and if you want to get at certain new aqua elements through the carbon toolbox the best way to do them in some ways the only way to do that is to use interface builder to design nibs in order to get at those objects and then there are some performance tools and all these performance tools work with your carbon applications the sampler performance analysis tool the malloc debug memory analyzer the object Alec object analyzer that is primarily for objective-c and then the chudd low-level machine tools will analyze anything as long as it's expressed in bytes but Xcode is not a world unto itself Xcode supports the external editor model that codewarrior and DB edit do so for example if you like the Xcode build environment but prefer euro your old familiar editor like BB edit or like Emacs you can use either of those text editors as your code editor inside Xcode we integrate with other editors you like and if you still have resources sadly res edit has not made the transition to Mac OS 10 but there are some very very good tools from third parties the constructor from Metro works and resource or that you can use on your resource files if you want to edit your Mac resourcer and if you double-click your resources in Xcode it'll launch constructor or launch resourcer and you can edit them there and go right back to Xcode so we integrate with all these other tools it's not a stove pipe technology we're open with other tools similarly we're open with source code control systems if you happen to have your code checked into a CVS or perforce repository will integrate nicely with that on the atomic day by day you know check-in check-out modify cycle and we integrate nicely with the administration management tools perforce was showing a very good one in their boots today and there are a couple of third-party and shareware CBF integration tools management tools that we integrate with xcode loves carbon we're working very very hard to make x the great development environment for your application we're making it easy to import carbon projects wherever they come from project builder or codewarrior it compiles Mac resource files whether they be dar dar SRC files ties in with existing resource editors in a seamless way it supports building nib files if you are moving to NIM files in interface builder it's the best way to use the new H I elements the best way to use carbon events and it supports combining carbon and cocoa in the same application there are a lot of new AP is that we have that or cocoa only and you can get to them from carbon using objective c plus plus and if you want to take your existing carbon app and start using some of the unique and interesting cocoa features xcode is the best way to start doing that so let's look at bringing a project into Xcode there are a few simple steps first you need to make sure you have a carbon application if you have a Mac OS 9 application that's still based on interface lab first thing you've got to do is carbonize it before you can bring it into Xcode because Mac OS 10 applications must be carbon to run in Mac OS 10 native and if you've got a 9 application carbonized it on nine first and then you can bring it into Xcode on Mac OS 10 then you need to bring it into mock oh ma ko is the code format for Mac OS 10 CFM is for mac OS 9 and 4 classic if you're going to be building a mac OS at 10 application we really strongly recommend you move it into the ma co format to take most advantage of mac OS 10 and to take most advantage of xcode most of the rapid turnaround features like six and continue and zero link only work in the ma co format then you need to adjust your build settings to get your project to build build settings are always very fussy and working in xcode is no exception so when you move a project either from project builder or from codewarrior impacts code you're going to be spending most of your time tweaking your build settings making sure that you're building what you want to build when and then the last step is when you finally get your project building you're going to have to look at your source code because the GCC 33 compiler has some diff from JCC 31 which project builder used and it has some differences from the code warrior mwc c compiler and you're going to need to make some changes in your source code in order to cope with that in the demo we're going to do today we're going to make exactly four changes in the source code to bring a large code warrior project over into Xcode so first step carbonizing your application I really shouldn't have to say this we've been talking about this for three or four years now just the quick steps you should have done this years ago if you still got a mac OS 9 only interface live only application you isolate your mac OS usage to just the subset supported by carbon lab you modernize it to use a new AP is you remove the linkages to interface live and start using carbon library at stubbed instead we still have posted this tool that will look at your application and tell you what carbon ap is you were using and not using that will help you make this transition if you haven't done that now do that now but MN come back at the end of the session and we'll talk the next thing is converting tamaco if you have a project builder application it's already mocco if you have a code word application i recommend the best thing to do is to change your projects from CFM tamaco in the code warrior environment where it's familiar where you've got more control over things where you don't have to be changing three variables at the same time codewarrior does a good job of building majko applications so if you just go into the target settings panel and change the linker setting to Mac os10 PowerPC majko that will get you a macho application and that will start bringing in all of the changes you need to make in order to make a mock o application if you have a very simple application that doesn't load shared libraries it doesn't bring in static libraries it doesn't call plugins if basically all it does is hit main and then run there's very very little to do it's just a binary loader format if you happen to have something that uses a plug-in architecture if you do some dynamic loading you'll have to migrate the AP is that you all in order to load those plugins from code fragment manager api's to the mock oap is what we recommend is to use the CF plug-in architecture in core foundation and CF plug-in is a way to dynamically load plugins that could be either CFM or mock oh and what that allows you to do is maintain compatibility with existing SIA CFM plugins but also support mocco plugins as well the only hard part is that if those plugins the CFM plugins happen to call back into your application and expect you to be a CFM application that's a particularly difficult case if you want to come to one of the feedback forms or down to the porting lab or catch me afterwards we have some techniques to deal with that they just involve making a lot of CFM glue that looks like a CFM link library in your application that calls in to the mock oh it's a tough problem but a lot of people don't have it if you have a project builder project importing into Xcode is very easy it's drag-and-drop Xcode is upward compatible from project builder files only if you start using some new Xcode features then does your project file become Xcode only if you just bring it from project builder into Xcode and build it and you don't switch to new compilers and you don't turn on features like fix and continue ER 0 length then you can take that project file and share it with a project builder user although once you start using Xcode your desire to do that is going to be very very damp and believe me it's just a much nicer environment to work with but let's talk about where your code really is now most of you have codewarrior projects let's talk about the steps in bringing a code warrior project into Xcode and especially doing so in a way that lets other codewarrior users continue to use the same source space you know we know that nobody switches whole hobbs but there is probably going to be a transition period where some users are using codewarrior some users are using Xcode you can do that successfully with the two environments it's not an automatic process but it's a lot easier than you think we take great pains to make it very smooth the first thing is that you should import your projects bottom up if your project is a tree of projects that first you start with some shared static libraries and then you build some dynamic plugins and then you build your precompiled headers and then on top of that your main application and then there's this side little runtime thing that you build it's best to start at the lowest levels and convert those projects one by one so you can bring those execute executables in to the higher levels of the project the second thing you do is after you import is that you need to move from the code warrior style pre-compiled header mechanism to the xcode style precompiled headers mechanism the two compilers have somewhat different mechanisms and you're going to get no joy in anything until you deal with the headers because one until you get your head precompiled headers right you won't get the speed advantages of Xcode and you'll you're going to get a lot of build failures and it's not going to be fun the third thing is if you happen to be using the power plant application framework there are a small number of changes you need to make in power plants for power plants to be compiled by the GCC 33 compiler and build against the Apple standard libraries a very small number of changes the power plant sources are really very clean and the GCC compiler is really quite compatible they're just a couple of changes you need to make and we'll show you then the fourth thing is you need to fix your target settings to get rid of some link errors and make sure that Xcode is building your project properly and then once you build but then you need to make a couple of changes in the resource files in order to work with the developer release version of xcode we're going to get these worked out by the time xcode 1 point 0 ships but right now there are some things you have to do to the resource files to bring them in and then you get to work on warnings and errors real differences between the compilers usually these are things that Metro works was lenient about the GCC is stricter about sometimes it's things that Metro works supported or did used in a different way that GCC interprets in and if different way often grey areas in the standard for most mainstream standards-compliant c and c++ code you can compile tens of thousands of lines without seeing an error so to do this demo I'm going to bring up the useful and lovely Scott took her who has put together an example of he did be importer that imports code Warrior Project and he's going to take an example of a fairly interesting code Warrior Project thanks Chris it's a little bit misnomer say I did the importer I basically took an old version of the importer and made it work a lot better so what I'm going to show you here today is we wanted to find a project that we would bring over and just show the whole import process from importing to then going through and fixing all the problems actually running the application and so we take the appearance demo which is a common power plant example and so just for those of you who have never seen it which is probably not very many this is appearance demo so it's basically a showcase for all of the power plant widgets and we thought this was a good example because it's small but it also uses power plant like many of you and we wanted to show that that Xcode can work with power plant you can run power plant and it just runs it works so equal sense so the first thing we're going to do is launch Xcode we're going to import the project so just say import code where your project lets me choose instead to see here I haven't passed two we unlike project builder we take the actual code warrior project file and also you can change them if you want although you can just by default it's just the same we also have this import global source tree that we support source trees now so if you have short stories and codewarrior we can pull them over at the pro app level in fact the importer creates a source tree to deal with the compiler relative paths you may have in your code where project so what we're doing here is we are using Apple script to launch code warrior and then ask it okay I want an xml version of the project then we take that XML and we go scanning through it and find all your files and because project builder likes to have all the headers in the project it's like to be very explicit we actually then Wow sorry I've never actually done it on a fast machine I thought I'd have more time what's the xcode comes back but anyway just to finish up we actually bring in all that stuff so when by this time what we're asking you is ok we want to know your encoding I recommend for the older prodigious pecially older project that you just go ahead with the mac electroman encoding because that's probably what codewarrior was that when you create the files that's what cobra was using so let's go ahead and start with the target you'll notice that you get a native target so we're not using the old project folder targets here you know we're using the new native xcode target and the first thing we're going to want to do is set up the prefix header as Chris mentioned will pre-compiled support right now is a bit different from code were so there's some things you need to do to make it work well so the first thing we're going to do is we're just going to double check and see what the prefix file is oops of course this could type life would be better so as you can see we bring over the prefix header so its appearance demo mock previously and we actually add this to your target so let me just move this out of the closest for a second and let me just find the prefix so there it is and so you can see it's right here but if we go and try to build I'm not even incredible because what's going to happen it's going to fail because it's going to bring an MSL the imported by default doesn't bring over MSL stuff so what we need to do is we need to replace this prefix file with one that doesn't use nsl we want to use the system libraries instead so what I'm going to do is trick is I'm going to fake out going to fake out Xcode okay and while Scott's doing that as if you go back to the slide yeah [Music] hey this is there we go there we go so Scott's going to be Julia Child and work in the kitchen Gator a little while while I talk about how the importer works miss wenlock cast her because he had we were doing this on a powerbook in rehearsal so we had timed so so as got said the importer applescript codewarrior to generate an xml file from the project file and then it imports that and then it walks the tree and looks for the header files and imports them and then it can also convert any dot plc files is fine it has codewarrior compile them into enthalpy lists and imports those info.plist so it gets as much content from your project as it can in one go what it doesn't handle is it doesn't handle metalwork precompiled headers binaries the binary formats for the two compilers are different for precompiled headers so we don't import those at all it doesn't really handle non source files in your project tree so if you have documentation files or HTML files or things like that we bring them over and add them to the project but we don't necessarily hook them in anywhere interesting it will not bring over CFM libraries or stubs in your target xcode is a mock o only build environment so we just ignore anything we find that happens we CFM and currently it doesn't bring over inter target dependencies if you have one target that depends on another target we're not going to link up the binaries because the binary was the binary that was created by codewarrior in the place codewarrior created it Xcode is going to create a different binary in a different place so you have to wire those up yourselves afterwards let me talk about precompiled headers while Scott's putting that together pre-code warrior has a concept that they will precompile anything a dot H file dot PCH file they'll even pre compile C and C++ files anything you can throw at the compiler they will precompile for you either from a menu item or from a directive inside a file or from a special pre-compiled header target in a project what you usually end up doing if you want to have a different phase to pre pre compile your headers is you have like a library target that builds a null library with the name like throw me away later and in the course of doing that pre compiles your headers and deposits them in a certain location where other targets expect them well Xcode works in a completely different way it's really much simpler you take your prefix file and every target has a prefix file and if you check a checkbox it pre compiles that prefix file when it needs to for that target that's all you need to do really you don't have to set up special targets and special projects to build it the build system manages when your PCH file needs to be rebuilt if if it needs to be rebuilt it rebuilds it if it doesn't it doesn't so it's pretty simple all you need to do is figure out the content you need to have in your prefix file put it in the prefix file put that prefix file into your settings and then check the checkbox and you've got precompiled headers automatically so look we can yeah so back to this okay finders being a little flaky so move on so what I want to go over now is there actually because this is a preview we haven't had a chance to completely move over to all the new build settings so I just wanted to go through a couple of things that you're going to need to do manually that when we were doing this we ran into one make sure you understand the first one is the C language standard by default currently it comes up to see 99 well for older projects we recommend that you set it to compiler default especially if using C++ you'll get all these errors and warnings about oh well see 99 doesn't make sense for C++ another thing is that for example in this particular case codewarrior will force C++ well the importer interprets that is saying oh used dash X C++ which will force C++ but it turned out that they were all sleepless floods files so you can just get rid of that in many cases also the eff exceptions and fr TTI options and the other cflags are just not needed because we turn those things on by default and then finally there is one kind of thing we're going to fix but you have to fix now yourself which is if you go to get your pre-compiled header to build properly if you're only using C++ currently what we found is that you're going to need to tell Xcode that you only want to c++ dialect it actually turns out with our pre-compiled technology because we have under the covers multiple different compilers we have to say which dialects you want to for the final one will take care of this automatically for the majority of cases right now you have to set it and then finally one of the new features you've been hearing about a zero link well unfortunately the compiler didn't have the importer didn't quite get the ability to set that for you automatically but it's really simple so I'm going to go to that now if we just go to the project inspector and go to style so we just want to add one thing which is we find 0 link it's actually understand it's under the standard build settings and you just type in 0 there it is you just want to check that on and notice I'm doing this in the development build style if you haven't heard we have these build styles and overlay our target the idea here is we only want to use 0 link when you're doing your debugging and you're developing when you actually go to make a deployment build you want to make sure 0 link is off because we don't want your shipping apps that are not properly linked so let me go ahead and we will build so just to give a more detailed out the boat build why of course this is part of the demo we expected to failure yes foot we expected a failure we didn't expect disk failure okay actually we expected this failure later we expected this failure later yeah so what we expected to be able to show you was that power plant isn't quite happy with me can we try one thing real quick here let's just try a clean you're right why is it trying to do this now I know because the demo God paid us what why is finder hanging on me because the demo got a problem right so we'll go to slide yeah so this is a power plant application and the failure you were host to see was not the failure that we're going to address and I'm slide go back go back work back alright i'll be a failure supposed to see so what you'll notice here is we have a bunch of failures that are in El stream this is inside of PowerPoint this is not any of our code in the example and so what we're going to have to do is now Chris can take well while I switch into the new which the new PowerPoint seventh-place Chris can go through the changes you often make the powerpoint which are really minor okay back to the slide so the errors you saw up there the second time when we got the correct errors on the screen were some differences between the GCC compilers interpretation of the power plant source code and the network's compilers interpretation of the power plant source code especially when it relates to how they use system headers since what we've done for you is my great you from the MFL majko headers to the actual apple standard library headers there are a couple of library differences that make a difference when using power plant and there's one thing where GCC interprets what we do differently what we document in the transition book which I'll tell you about later and what you need to do to your power plant sources these you may need to make for clean compatible changes to your power plant sources and then GCC can compile any power plant application there are some changes to the L exception class which subclasses the system exception class and the system exception class has throw specialized errs on its destructors and it's what method so you need to add those to the power plant l exception class b so that it will match the underlying system exception class there's a place in LGA tabs control input dot CP where it uses multiple instances of a local declaration inside cases of a switch statement and GCC doesn't like the way the code works there in it requests that you move the local declaration outside the individual cases so that's fairly easy to do and in else screams not HD streaming operators for long double and short double are already declared elsewhere in the Apple header so you get a multiple definition if they're Rida clared in the code in the power plant headers so you need to just taste those out and usually we do a pound if canoe see pound round it's not going to see then include those so that your power plant sources can be compiled and built by codewarrior still even when you're also building them with GCC so this is pretty much all the source changes we have to do and they're all in power plants to make the appearance demo run so what Scott's doing is he's actually switching over to a fixed version of power plant and then he's going to rebuild which I have already done and now he's rebuilt and all of those compiler errors have gone away and now he gets the errors we saw before which a resource area at the bottom it says error file res merger dot C failed to open source file negative 39 so if we can go back to the slides now come back get that and come back because he says we're going to see this later so this is the error we're seeing now there is a bug in the Reds merger tool which if you ask it to generate data fork resource files and you provide heterogeneous input that's mixed data force and resource for resource files it gets confused and fails and we will fix that by Xcode 1 point 0 by Panther but for now if you're bringing a project in that has resource files and the fork in which the resource files originated is different from the fork in which you want the resource files to go and to build a Mac os10 packaged applications you generally want your resources to go in the data fork of the resource files in the resource folder then you're going to have to do some massaging of your resources in order to get them to build with Tex codon and what we did here was we basically took all the daughter RS rcmp POV files both in the parents demo itself and in power plant itself and we just be read them in two daughters and brought them in and that has some extra advantages because then the indexer and Xcode can search them and you can have them in text form and you can check them in more easily to perforce or CVS which are not really resource for kawai so the what we've done here is we've moved all those daughter rsrc files in de dar dar files to get around the resource error now we're going to go back to get past the resource area right in fact the time can watch it filled so if you notice really fast there we did the resin and so now it's going emerging the resources so this is where we have the time to now talk like until you'll notice as we come in just like code where we have this little code column so you can see the code and you can sort by that while we're going on we also provide these check marks to indicate what needs to be built to the right of the code here you'll notice we have I'm errors and warnings on a profile basis so this is substantial amount of code warrior code both the appearance demo itself and the power entire power plant framework that's compiling without error in GCC with very few changes so our challenges so far have been get the header files right and we've done that get the sources right and we've done that and get the resources right and we've done met and once we have all of binaries in place then the linker kicks in and giving the linker right is the last phase before you have a running application and can debug so now we're linking and we will see the books ability to exceeded but it lies and it lies because we turn zero length on right zero link defers link errors to execution time so now if you try to run it thanks thanks and then nope didn't run it didn't run let's check the run log so what you'll see is you'll see this unknown symbol and then some bizarre name really what it comes down to is currently in the pre-release we when you use zero link and your C++ application you have to link against the standard C++ library for the final release we should be able to take care of this automatically but for now you're going to need to set this in other linker flag so I'll take you through that right now if we go back here what i can do is let's just bring up the standard build settings will look for a link oops not mean to bank let's see so I will be brave one other thing you will have to do is usually you have to touch a file we em there's a few dependency cases that we don't deal with in the preview bill to clean it again and now we just run it we can run and it launches there we go unless you say oh but God what Scott this was built with Xcode oh it must look different faster yeah you swapped the power plane yeah so that's why I decided right it's too good for Maria so act out a fight yes rectifies just want one clarification that actually didn't that what it was running into their did not have to do with the changes we made a power plant it's with some other issues yeah that we know about and so in linking the last step is the important apps your key target settings it tries to read as much as it can from your project builder project file and translated into the linker flags that you need to set in your in your Xcode file there are some things we need right now you need to include dash else STD C++ in your linker flags will take care of that for you in the one point 0 version an important thing is that often the importer if you've built a mock Oh project in left got a file sitting around the important in a lot of code warrior day files and if those have been linked with the code where linker then the Apple majko linker is not necessarily going to like them so you need to throw out the dot a files that are that have been imported and if they're built by sub-projects then you need to re add those into your project so that's what I was talking about before of the if you're building from the bottom up you need to rewire all of the subsidiary parts back into your project as you built it in 10 version we expect to have much better inter target dependencies and inter project dependencies do more of that for you automatically but with the disks you have in hand that work you need to do manually and then the main thing is you notice that the first time we built it it said build succeeded it linked it tried to launch men gotta run failure you're going to see that a lot if you have zero link turned on so what we recommend doing is if you have a build succeed using zero link what we recommend you do is that you switch over to the deployment build style which turns off your link try building again and then you'll see your real linkers you want to know about those link errors because they are linked errors there are things that will happen at runtime either early or late depending upon what they are but don't take build succeeded as everything's fixed always go to the deployment style and try a build there just to make sure it works ok development and deployment styles are really really powerful and they'll make it a lot easier for you to work with multiple targets in Xcode then you've had it before in codewarrior development and deployment styles as honors explained yesterday are extra sets of flags that override other settings in your target and what that lets you do is it lets you have a debug version a profile version a beta test version and a final version of your application with the same target without having to have four separate targets and what that means is if you need to change a target setting or if you need to add a file to a target you don't need to change it in four separate places you just change it in your one target and then that is layered on top of by the four different build styles it really makes it a lot easier to manage your target so we recommend that instead of you know when we import your code Warrior project's we're going to import all of your targets even if there's a debug version in the production version what we recommend you do is that you essentially delete the debug target from your Xcode project just use the production one and then set all of your debug settings in the development build style of the production target and that way you'll only have one target to manage much less complexity and you'll have much better control over what you want in your debug targets okay we've talked about that we've done that demo now let's talk a little bit more about the compiler the compilers are different the mwc c compiler comes from a mess long long line of very good quality metro works compilers they've been working on it for a long time they've been keeping up with the standards they've got a really good c + c and c++ parsing in really good code generation but it is a separate world from the GCC code stream which has been worked on for a similarly long time by different people sometimes with different objectives and even though that there there are common standards that unite the two compilers there are a lot of things standard doesn't address and there are a lot of places where both compilers are non-standard that you will find when you bring your source code from one compiler to another the first things you'll notice is that GCC is philosophically opposed to pragmas preferring you to do all of your control of code generation on the command line or in our case in the target settings and since codewarrior is very seldom used with the command line they use pragmas for almost everything to control their code generation so the major change you're going to need to make is things that you used to express in pragmas in codewarrior you will have to translate when possible to per target or profile build settings in xcode second thing is that the warnings are very different even people moving from project builder to code warrior project builder to xcode are going to note that GCC 33 is a lot more picky about throwing warnings for for example promotion of signs to unsigned integer in a parameter list you're going to get a lot more warnings when you build your project now what you could do is just turn off all warnings and get a much cleaner build we don't recommend that GCC's warnings are correct they may be pedantic they may be irritating but they are correct they're often things you need to look at in your code and I've had more than one case recently of somebody saying my code doesn't work it breaks here when I do this and then when we go and turn warnings back on we see that the compiler was complaining that you did this in your code and we're just going to do the best we can but it might not work at runtime and of course it didn't so ignore compiler won't compiler warnings at your peril they're really important they really do mean something and the third thing you'll notice is that if you do in lining in order to to reduce your source code bulk but try to get some good optimization out of it the in linings philosophies of the two compilers are different the code warrior compiler has in low in line thresholds by depth of repeated in line inclusion the GCC compiler has its inlining threshold cut off by the bulk of the size of the inline function and you may need to adjust your parameters up or down to make sure that what you want to get in line does get in line and what you don't want to get in line because of code bloat falls outside the threshold there's some other differences and these are a little more serious if you've been using code warrior for a long time you probably have put C++ code into dot C files because codewarrior doesn't care now GCC does care and GCC in its native state will tell you if you use C++ isms that is things that are specifically C++ and not just c99 extensions to see to make it look more like C++ it will warn you if you try to declare a class in the dot C file it will give an error if you tried a bit clearer a class in the dot C file once again you can cheat and turn on dash X C++ and it and GCC will happily interpret all your dot C files as C++ but the rest of Xcode which doesn't get information on the compile from which language semantics you used for which specific file may get confused for example the debugger applies debugging semantics to your source code based on its extension and so if you have a class declared in a dot C file the debugger is not necessarily going to see that well or clearly so I really recommend it if you have C++ file C++ code you change it to dot CP files and if you have just straight see toad you could leave that in dot C files that's probably the number one thing we see in projects moving over from codewarrior you C++ code in C files GCC differs where the standards are undefined the order of calling C++ static initializers especially if you're moving from CFM tamaco where the order of library initialization may also be different if your code relies on a specific order of initial ation the initialization of static initializers there will probably be problems and you'll need to work those out and debug those very carefully you can have some fine-grained control over it by link order but it's something that you need to expect is that your static initializers may not be called in the deterministic order you saw mainly because ma co loads modules lazily and dynamically where CFM did everything all upfront second thing is that there's some disagreement on how you pass trucks and unions that are packed into quantities of smaller than 4 bytes there are some differences there most of these differences are not clearly documented either in the code warrior documentation or the GCC documentation you can join some of the apple mailing lists or look on Usenet for either of the code warrior groups codewarrior mac or comp system at programming code warrior both of those have pretty long discussions of the differences between GCC and the code word compiler in these respects and finally GCC uses the C and C++ in fact it supplies the C and C++ standard libraries that shipped with Mac os10 in both static and dynamic form and codewarrior supplies its own libraries the Metro work standard libraries or msl that go with the compiler and here to Fort have been statically linked into your applications when you move from codewarrior to GCC you are moving from the MSL standard libraries to the Apple standard libraries and there are some big differences there you need to know about the good news is that if you're building for ma co the MSL standard libraries are essentially a thin layer on the Apple standard libraries so most of the behavior is the same except for a small layer of differences the other good news is that MSL has been supporting whr tea and w string wide character support in C and C++ for many years but they couldn't supply it in their macho libraries because it wasn't in the underlying Apple libraries as of Jaguar it's now there in Panther so if you have programs that have relied on whr and w string support in ms l and you couldn't go tamaco because of that you can do that now in Panther because that supports in the underlying library and it's taken advantage of by the MSL standard libraries and this is a good implementation of W char and W string it's the citrus project it's been heavily tested to net VSD it's not something we invented ourselves it's really good code another thing you'll run into is that Apple libraries tend to use the global namespace not the STD namespace for many things many things that Metro work standard libraries put in the STD namespace this may mean that you need to make some changes to your code if you're expecting singing things to be in the STD namespace it may mean that you need to change some conflicts where things that you have in your code will conflict with things to do now in the global namespace that you expected to be safely partitioned in the STD namespace if you're using the standard template libraries metro works stl has some very useful functions for debugging that you invoke if you set a macro setting that macro is innocent in Apple's stl it does nothing you lose that debugging capability but it causes no harm and then Apple libraries don't have certain Metro works extensions that they've added over the years for example FF spec versions of the POSIX file system calls since we're an underlying UNIX operating system we really do expect you to start using some of the underlying file calls or use carbon you know use all carbons or all UNIX and not necessarily this strange mix of making a POSIX call with an FF SPECT as your file reference we've added some compatibility features to make it easier to bring large quantities of code over from codewarrior to GCC one of them is we've added some pragma support not a lot but it's getting better we've added Metro work style inline assembly if you happen to have the inline a PowerPC assembler code you can bring that in from your code warrior project to your Xcode project we brought several large projects over one of them the mac main video game environment which is tens hundreds of thousands of lines of inline assembly and we compile that so if you've got a lot of inline assembly don't worry about bringing that over some code warrior we can read it now once you're in Xcode you want to take advantage of the Xcode features the reason to bring your project over is not because you're bored with codewarrior but because we've shown you some compelling things in xcode such as the zero length of predictive compilation the fix and continue the debugging things i'll show you tomorrow that you really want to take advantage of how do you turn those on well it's really pretty simple the prerequisites are you have to use native projects which are done by default when you bring it in with the importer if you're bringing in a project builder project you have to upgrade your targets from JamBase targets to native targets and to get most of these features you have to move to the GCC 33 compiler which you can use in the project settings dialog is change your compiler to system default or GCC 33 once you're there you move to the the JCC style precompiled headers to get GCC's performance if you don't move to the precompiled headers the compiler is really slow it's just as slow was turning off precompiled headers in Metro works the other thing is that using precompiled headers just from frameworks gets you a lot but the more of your project headers you can precum precompile the better really the more headers you precompile the faster it is you can enable predictive compilation and that means we will fire up the compiler in the background while you type and that will really get you a speed benefit as I said the other day when you include carbon carbon H in any source file the headers that are brought in are three and a half megabytes of source now most of you don't have anywhere near that in an individual see file so the ratio of headers to source in a given compilation unit it's huge and the more of that we can do ahead of time the faster the couple hundred couple thousand lines of actual C C++ we need to compile will go so predictive compilation will really speed up your turnaround time by doing most of the work in the background while you're typing zero length speeds up your fix build link relaunch cycle by not having to relink all of those modules that haven't changed its really a lot faster I mean it can cut a 30 second link down to 10 seconds fixing can't in fix and continue can cut that down 20 seconds by actually not having to have you stop the application in the debugger quit it fix it and relaunch it if you can fix something without quitting then that saves both of the QuickTime and the relaunch time and all the time it takes to get back to that point in your program where you're doing your Diagnostics and then if you happen to have C++ projects and big C++ projects distributed builds can really help you with your large world builds it's not necessarily good for incremental Galatians it's not that great for C code because C is not computationally intensive to compile and sometimes the network transfer time will exceed that but if you have big big C++ files that take a long time for the compiler to work on if you can send those out to multiple compilers in parallel you can see some quantum increases in your build time by turning on distributed builds let me talk a little bit of how packaging and localization because it's the last thing you need to do if you're bringing a project over a carbon project over to Xcode you may also be making the transition from a to fork resource-based file to a packaged file let me walk through a little bit of that when you package your target you pick what you're going to be doing an application a plug in a shared library a framework tool in Xcode you pick that up front right now we don't have the capability to change the target style once you built the target so you need to know what you're doing up front and it's kind of hard to change from a static library to a shared library and right now we don't have a capability of cloning targets so just make sure to know what you're doing ahead of time most targets are packages almost everything except a static link library and a UNIX tool will not create a single file but will create a folder with a bunch of files in it and the trick and packaging is figuring out what files to put where in that package technote 2015 explains all about the various package styles and what they are if you don't know what I'm talking about read that technote first Xcode puts things where they belong in your package automatically right now it doesn't have a copy files build phase like project builder did that lets you do manual overrides we will add that by the one point 0 but right now if you put a resource file if you put a header file if you put a you know compiled code into your project xcode will put it into the right place in your package automatically because it knows the rules by which packages should be built it takes all the target settings from the target settings in the project settings it builds those into the info.plist file that puts the info.plist file where it belongs it really takes a lot of the manual effort out of that working with resources as i said we read our files and we read our SRC files we also will read PPO be files and merge them into your resource your resources file and we interact with resourcer constructor and interface builder if you're localizing your resources localizing resources in a packaged application is different than what you used to do in CFM in CFM what you used to do is you'd have 124 Kyle with all of your code and then the resources for one language and then you'd produce another file with the same code and the resources for a different language and then you'd produce another file with the same code and the resources for a third language well but the way you do it on Mac West Ham is that you have one folder hierarchy called a package and it has one copy of the code over here and then it has different folders called dot L proj folders for your different languages and your resources your nibs your strings anything language dependent goes in the dot l prods folders ok it's a different way of thinking and you deliver one binary that's multilingual rather than localizing your binaries Mac OS 10 apps are multilingual by default and the way you make them multilingual is you take a file that has language dependent constructs in it like a strings file or a nib file or resource file you go to its inspector and you look at this thing called localization variants and you can add a locale and it makes a clone of that file that you then localize and then it puts each of those into the right elkridge folders so Xcode does this for you automatically it will manage your hierarchy of localized versions you can start with English and then localized for their let me talk briefly about interface builder for carbon Eric did a great demo of the new struck in interface builder interface builder is the Aqua design tool the Aqua design tool and as we evolve aqua for both carbon and cocoa we evolve interface builder to give you access to those and there's going to be more on interface builder and carbon in the building a modern Mac application session which I'll tell you about later I just want to retouch on some of the things that Eric talks about new in interface builder for carbon is support for new carbon controls like the H I image view the H I search field the H I scroll view and the H I text view you can drop these into your nib files directly from interface builder for your carbon application we've also added the tiny controls if you're building very small palettes we're going to start using these in the Panther version of xcode because they're very very useful for things like inspector panels where you want to pack a lot of buttons into a small space these are now on the palette for interface builder for your carbon applications and new our control properties these this is static information that you can enter into interface builder that lives behind an object that when you load that object from the nib these constants are already set in that object so your AP is can query that object that it loaded from the nib and get these constant values from it so if you want to parameterize things or if you want to preset titles or if you want have to have alternates or anything your API wants to do with information that you would normally put in a resource fork you can put them behind the objects in your nib file and this is a very powerful thing they will give you back a nib some of the things that you used to have in resources and finally because we've changed the format of the nib file for Panther there's some fairly strong nib file compatibility checking that you can do in interface builder itself that you can tell when you're building it whether you're using using pants or specific functions whether you're using Jaguar specific functions and how backwards compatible your nib will be so you can be careful about not accidentally constructing an application where all your code might run fine on Jaguar but it loads a nib that happens to exploit Panther specific functionality so your application will fail when it runs on Panther okay just about right on time going to wrap up hope you've learned from this session that we've given a lot of thought and Xcode to your carbon applications especially bringing your carbon applications over from where they exist now which is most likely in toad warrior we build C++ code really well we adhere to the standards we build it fast we build good code we build good applications to here to the Mac os10 standards we build packages we use resources we use nibs you're going to find that X code is the best way to build your carbon applications on Mac OS 10 there's a lot more you need to learn than just listening to my presentation there's a lot of documentation in the Xcode tool package there's a lot of documentation in the system overview for the CVS and / forced integration there you can go to the CVS and perforce sites for those the most important book to cover what I've been talking about today is this moving projects from codewarrior to project builder it's not on your distribution but it's in your ADC account login to your ADC account and you can download it from the downloads folder you can also get hard copies of it down in our porting lab which is it's called the Mac os10 laboratory down on the second floor down on the first floor the integrating carbon and cocoa and your application is a really interesting book if you want to start learning how to take advantage of some of the cocoa functions from your carbon application and then of course the definitive guide to the maca runtime architecture and the new CC plus plus plus objective c compiler if you're moving tamaco and GCC for the first time those are going to be indispensable resources of course there are xcode in interface builder release notes on the distribution you have and there are some places to go for tech notes text UAE's and sample code they're all on the ABC homepage Godfrey did Georgie is a champion for this technology contact him if you have questions we have the development tools engineering feedback which is an Xcode dash feedback at group apple.com please post bug reports we want to make this a great carbon development environment and if there is something that we're being bonehead about or we've forgotten about in carbon development please let us know we'll try to get it in by the 10 and look at the mailing lists on listal com or the Usenet groups I'm going to be living on cops if Mac programmer for the next few weeks listening to what you have to say about it if you happen to be unused net here are some great sessions to go to feedback forum nine today two o'clock let us know how we're doing debugging services for Mac os10 this is the overview of Xcode and gbb today at three-thirty that's not going to be a carbon oriented session that's going to be a gbb oriented session debugging and tuning carbon applications I'll be in the big room tomorrow morning nine o'clock and we're going to show you some great debugging features for carbon applications using Xcode software testing tools there's some fun stuff going on there for automated testing of your carbon application using Apple tools and using third-party applications that's tomorrow at ten-thirty and the session I was referring to before how to write a modern carbon application if you've been using basically the same api's and resources for the past nine years and you don't know what nibs are and you don't know what a chive you is there's a completely different way to write a great carbon application and you should learn about that two o'clock tomorrow afternoon you