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