On Aug 16, 2012, at 17:58 , Stephen Kay < email@hidden> wrote: I'm porting an old CodeWarrior project and doing it initially in XCode 2.4.1
on 10.4.11, on a PPC machine where I used to build the CW versions.
So I got everything to compile, link and run, on the PPC machine. The
project is set to use the current OS to build against, deployed against
Compiler Default.
I then moved it to an Intel mac that is also running 10.4.11, and XCode
2.4.1 (identical). When I compile it on that machine, I get a large number
of deprecated warnings such as:
warning: 'RectRgn' is deprecated (declared at
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.frame
work/Headers.Quickdraw.h:3072)
I understand that QD is deprecated, but why don't I get the same warnings on
the PPC machine? Both machines are using XCode 2.4.1 and Mac OS X 10.4.11.
Same project. Any ideas on what could be different?
You're seeing the consequences of building against "current OS". That is, you're building against the actual system frameworks used by the running OS.
By definition, every minor version of OS X (10.4.x) is a different set of frameworks, in the sense of being different files. In the case of the architecture change, the minor version number didn't change, but obviously the files did -- if for no other reason than to include the executables for the new architecture.
I'm not aware of any guarantee that the header files in the system-supplied frameworks won't change when the executables themselves change (for the above reasons). What you're seeing, apparently, is that the header files *did* change across the architecture change.
This doesn't normally affect developers, because the normal practice is to build against an SDK -- a set of stub libraries for the system frameworks, plus a set of header files -- and those don't change except at major version numbers. (Though perhaps there are cases of small corrections of outright errors, but I can't recall running into any examples. In some cases, errors in the SDK *didn't* get fixed till the next major version number.)
I seem to recall you had a reason for using "current OS" instead of "10.4 SDK" as your base SDK, but I don't remember what that was. It would be better to build against an actual SDK if you can.
However, instead of going backwards to deal with that, I see two possible strategies of going forward:
1. Ignore Intel Macs running 10.4.x, and port your running app to a newer SDK in a new Xcode (say, the 10.5 SDK in Xcode 3.2.5, which IIRC is the last version of Xcode that contained the 10.5 SDK). Once that's done, the architecture should no longer be a consideration.
2. Stick with Intel 10.4.11 and fix the code to not use the deprecated API.
BTW, it's not clear what your *eventual* target OS is for this app. (Again, you may have said, but I don't remember the answer.) I seriously hope you don't need to support 10.4, or 10.5 either, except in the interim porting phase. Now that you've freed yourself from CodeWarrior, I'd suggest you move into the modern OS X and Xcode and non-PPC era as fast as possible, rather than creeping along SDK by SDK.
Of course, there's a decent chance that the last-expressed recommendation is utterly, deeply wrong. :)
|