Ken;
Thanks for the quick and helpful response!
You seem to have assumed that you can only compile against the 10.4
SDK by going back to Xcode 2.5 (and thus using an earlier compiler).
No I brought the application back to the 10.5 machine and have left it
compiling against the 10.4 SDK for now.
Trying to decide whether to return to using the 10.5 SDK was the
genesis of my question.
In general, your choice of SDK should be dictated by the latest
features you want to use. If you don't want to use any 10.5-or-
later-only features, sticking with the 10.4 SDK is safest.
I want to deploy to 10.4 and have avoided using 10.5 features to keep
the code base clean and simple.
My plan was to prove out the product idea using the widest possible
audience (10.4) using the simplest most widely understood and sampled
code - 10.4 only.
If successful, then version 2 would be a 10.5 only product developed
using a by then more battle-tested 10.5.
Version 2 is also then a clean code base because it also avoids all
the OS-version conditionals you mentioned.
Also, what do you mean "the underlying code is cleaner"? ......
One caveat with simply using the 10.4 SDK, though -- the 10.5
frameworks contain a number of bug fixes
That's what I meant.
...(bug fixes) which are only enabled for binaries linked against
the 10.5 SDK. This is both a good and bad thing. It means your
program works consistently on Tiger and Leopard, which makes testing
easier. But it might behave consistently incorrectly due to the
bugs. Check the various Leopard release notes for specifics.
I'm afraid I don't understand this comment.
What do you mean "..behave consistently incorrectly due to the bugs.."?
Can you refer me to a specific item you might be thinking of here?
So in sum, I think what you are saying is:
Stick w/ 10.4 SDK as the safest path.
However there might be bug fixes which you could benefit from by using
the 10.5 SDK.
To determine whether or not you actually do benefit from 10.5 means
you have to learn more about it by reading the Release Notes.
Does that sound right?
So based on this reading of your comments and a few minutes with the
XCode documentation I scan the AppKit Release Notes for Leopard and
find the following:
NSCompoundPredicate
For applications linked on Mac OS X 10.5 "Leopard" or later,
initializing an NSCompoundPredicate now copies the subpredicates array
rather than retaining it. Applications linked on Mac OS X 10.4 "Tiger"
continue to only retain the subpredicates array for binary
compatibility.
Well this appears germane to my application as I do use compound
predicates.
Judging by the scope the Release Notes and the speed with which I
could locate even one germane issue I am convinced that my original
instinct to use the 10.5 SDK because the code base is better IS correct.
But I am puzzled by your "good and bad thing" comment...
Thanks Again,
Steve
On Oct 18, 2008, at 12:18 AM, Steve Cronin wrote:
I have developed an application with XC 3.1 on a 10.5 Intel machine
using the 10.5 SDK w/ a 10.4 deployment target.
(No GC for me!)
In testing I immediately ran into a few difficulties on a 10.4 PPC
machine.
In the course of tracking down these issues I ended up installing
XC 2.5 on this 10.4 PPC machine.
I actually compiled the application under the 10.4 SDK on this
machine so I could run it in the debugger.
(I had to make surprisingly few changes to get this to happen -
none that I am unhappy about)
Converting all .xib to .nib being one major aspect (and where I
found the offending bug [filter predicate bindings...])
In fact, this exercise has left me with an increased confidence in
the application's behavior in this environment.
So I've moved the modified project back to the 10.5 Intel where it
happily compiles and runs still using the 10.4 SDK and .nibs.
So, given all that, am I correct in wanting to move the project
back to the 10.5 SDK because the underlying code is cleaner and the
compiler output is better?
Also, what do you mean "the underlying code is cleaner"? You are
linking against the frameworks dynamically. You get the framework
for the OS on which you're running. Regardless of what SDK you link
against at build time, you're still linking against the libraries of
your runtime environment.
In general, your choice of SDK should be dictated by the latest
features you want to use. If you don't want to use any 10.5-or-
later-only features, sticking with the 10.4 SDK is safest. The
reason is that the compiler will warn you if you accidentally slip
up and make use of a newer feature.
If you want to make use of 10.5 features but still deploy to 10.4,
you have to take extra care. That's why it's not good to do so
accidentally. You need to conditionalize all uses of 10.5 features
based on their availability at runtime (checking that symbols aren't
NULL and using -respondsToSelector:) and provide fallback code for
the case when the feature isn't available.
One caveat with simply using the 10.4 SDK, though -- the 10.5
frameworks contain a number of bug fixes which are only enabled for
binaries linked against the 10.5 SDK. This is both a good and bad
thing. It means your program works consistently on Tiger and
Leopard, which makes testing easier. But it might behave
consistently incorrectly due to the bugs. Check the various Leopard
release notes for specifics.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
