On Jun 11, 2008, at 11:40 AM, Sherm Pendley wrote:
Yes, in fact it does matter. If Xcode resolves the symlink and stores
a direct reference to libz1.dylib, then it will continue to use that
even if you later move to a newer SDK with a newer version of libz.
When ld resolves the symlink, it does so each time you build, so
you'll always get the correct version for the SDK you're using.
The older versions are usually symbolic links to the newer ones
anyway, so if an app links against libcurl.2.dylib or libcurl.3.dylib,
they end up getting libcurl.4.dylib anyway. The exception to this
would probably be if the newer version changed the API such that it
would break your old code, in which case you'd want to be still
linking against the old library until you'd updated your code anyway.
That's why (well - one reason why) you need to use the SDK that
corresponds to the oldest version of Mac OS X on which your app will
run. If you use a newer SDK, the symlink will resolve differently
and
you'll end up linking to a library that isn't available on older OS
versions.
The problem comes up when you want to use a method that's only
available on
10.4 and higher (checking the OS version first so that you can
gracefully
degrade on 10.3.x), or when Apple decides to deprecate a whole
bunch of
methods in 10.4 and replace them with methods that are only available
starting in 10.4, in which case you have to use the 10.4 methods
inside OS
checks to avoid using deprecated methods on the current OS.
My solution for that is simple. I don't want to write my code twice,
so if I want to support 10.3, I write it using methods that are
available on that version. And if I need to use methods that *aren't*
available on 10.3 - or an entirely new framework, such as Core Data -
I don't even try to support 10.3.
There's a few reasons I don't do that:
1. The more users can run your app, the more potential customers you
have.
2. The more users can run your app, the fewer e-mails you get asking
"why can't I run this app?"
3. Relying on deprecated methods can cause an instant headache if
Apple ever decides to remove those methods (or if they eventually
start requiring you to compile for 64-bit or something).
4. Sometimes a method gets deprecated because its replacement has
better performance or has some other advantage that can make your app
better if you use it.
5. Sometimes a new method allows me to add a cool new feature that
wasn't possible on older OS versions without a lot of work, but this
feature isn't so important that the app isn't useful without it. In
this case, I can just implement the feature on the current OS, and it
gracefully degrades on older OS versions (maybe a menu item is greyed
out or something).
6. Often times a new method that shows up in a class can make your app
better if you use it. What I often find is that Apple adds a method
that does something I'd previously been using custom code in a
subclass to do, but it does so in a manner that performs better or is
more elegant in some way that is noticeable to the user. Or maybe it's
just cleaner and my custom subclass code is kludgey or ugly. Either
way, I would change my subclass method to do something like this:
if(tiger or better) {
return [super doTheOfficialThing];
} else {
// do my custom crap
return whatever;
}
Of course, this is for when an existing class gets some new methods
that I like or something. I of course wouldn't use something huge like
CoreData and then try to target 10.3, as that would just be silly.
I think this is pretty far off topic by now, though.
Charles
_______________________________________________
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]
