Re: CodeWarrior to XCode
Re: CodeWarrior to XCode
- Subject: Re: CodeWarrior to XCode
- From: Calum Robinson <email@hidden>
- Date: Thu, 26 Aug 2004 17:22:19 +0100
On 26 Aug 2004, at 15:36, email@hidden wrote:
Note that my perspective here is coming from years of work using
CodeWarrior and porting code from Visual Studio to CodeWarrior. Also,
these notes come specifically from our work moving Knights of the Old
Republic (KOTOR) from CodeWarrior 9.2 to XCode 1.5.
We (Zonic) have recently moved 2 of our projects over to XCode (Total
Immersion Racing and Warrior Kings), which have also gone down the VS
-> CW path. I should point out that it was XCode 1.1 which we used (and
had to give up on in the end).
5. Single-precision floating-point functions like acosf, cosf, etc are
not in the standard math library (libm). They are only available in
10.3+, in libmx. A similar situation exists for wchar support.
wchar support was one of the bigger problems we ran into - VS and CW
both use a 2-byte wchar, whereas 10.3 and above have a 4-byte wchar.
Having a wchar_2 type that wchar gets defined as via a macro isn't
enough, as there are wide string constants (L"foo") in some of our code
that the compiler generates as 4-byte wchar strings.
Dropping 10.2 users may be feasible in a year from now, but at the
moment they are still a significant portion of our user base.
7. We have routines that override standard library calls at link time,
like fopen, etc. ZeroLink causes problems such that our overrides lose
out, so it's best for us to keep ZeroLink off.
We get around this with macros for fopen etc. (e.g. that redefine them
as zonic_fopen), which has worked quite well so far.
8. Dead-code stripping
We haven't tested the dead-code stripping yet, as we only tried to port
to XCode 1.1. It would have been interesting to see the results using
dead-code stripping, as a debug build of one of our larger C++ projects
produced an executable (not a bundle - just the Mach-O executable) that
was 600MB in size (it took about 10 minutes on a dual G5 to load gdb).
The CW debug build was ~5MB. At that point we decided to hold off the
XCode porting until dead-code stripping was implemented :-)
13. Build styles are fairly useless for our projects, since they don't
allow us to easily have different libraries and source files for debug
and release builds.
We still haven't decided if we want to use build styles or not. At the
moment we build all of our libraries as sub-projects (so the build
style of the application is used, which negates the need to have
separate debug & release libraries). However, it's possible that in
future we may have to build an application that depends on a 3rd-party
library which we don't build from source, so sticking to separate
targets from the outset may be safer.
I did run some performance tests on the game when we finished. On my
Dual 2.5GHz G5, performance was almost immeasurably slower in the XCode
build, by maybe .5 of a frame per second. It was well within the margin
of error, enough so that I'd call it even with CodeWarrior.
We did get Total Immersion Racing up & running with XCode, and
performance seemed to be similar too.
Compile times for us have been OK with XCode, with the exception of
large projects that use a lot of complex C++ (templates etc.). CW can
get through those a lot faster. Having distributed builds & an office
full of dual-processor G4s does help, but XCode still has a way to go
before it can match CW in the time to compile a single file.
I'd appreciate feedback from other people who have had experiences
porting code from either VS/VS.NET or CodeWarrior to XCode. In our
KOTOR test, the code had already been ported from VS.NET (VC7) to
CodeWarrior, so it's unclear to me if there are any advantages that
we'd see if we went directly from VS.NET to XCode.
Although XCode has worked out quite well for smaller projects, the
large C++ projects that we have ported from VS to CW were quite
difficult to get up & running in XCode. We have filed a lot of bugs
since we have started using XCode and we do intend to switch over at
some point, but at the moment CW is reliable enough for us to continue
working with it.
Calum
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.