Re: Installing/distributing frameworks
Re: Installing/distributing frameworks
- Subject: Re: Installing/distributing frameworks
- From: Scott Tooker <email@hidden>
- Date: Sun, 29 Jul 2001 11:24:36 -0700
On Sunday, July 29, 2001, at 10:32 AM, Ondra Cada wrote:
>
R.,
>
>
>>>>>> R. Tony Goold (RTG) wrote at Sun, 29 Jul 2001 13:03:39 -0400:
>
RTG> I'm very curious to understand how this works... If I have
>
RTG> /Applications/Poodle.app containing Dog.framework 1.0 and
>
RTG> /Applications/Terrier.app containing Dog.framework 1.1, does
>
this mean
>
RTG> the next time I run Poodle.app it will use Dog.framework 1.1 (from
>
RTG> Terrier.app) unless its code explicitly states that it only
>
wants up to
>
RTG> 1.0?
>
>
It's a bit more complicated, but this is the gist of it.
Um, currently there is no way to accomplish this. In Cocoa you can
look for a given class or method to see if certain functionality is
around, and in Carbon you have Gestalt which provides similar
information (though more feature oriented in many cases, like 'Is
ColorQuickDraw installed?'). Also, it should be noted that when
applications currently link against frameworks, they link against
the current major version of the framework, so you can't
specifically link against a 1.1. versus a 1.0 since that would
require linking against a specific 'sub-version' of the framework.
this is another area where we are looking to improve things so it
is easy to to develop an application on version x.y and have it run
on a previous version x.(y-1).
>
>
RTG> Does this only apply to applications installed in the
>
/Applications
>
RTG> (and /Developer/ Applications?) folders?
>
>
And some other locations, but yes: it applies only to the apps
>
installed on
>
standard locations. It is *possible* though that the system updates the
>
tables whenever an unknown application is run, whatever path is
>
resides at
>
(provided it's a local one) -- this I don't know.
The framework 'search path' used is independent of where you
application is located, Currently, dyld will look first at the
installation path given. If the framework cannot be found at this
path, then it searches the fallback locations in this order:
~Library/Frameworks, /Library/Frameworks,
/Network/Library/Frameworks, /System/Library/Frameworks.
As I stated in a previous message the only special thing about
/Applications and /Developer/Applications is that LaunchServices
automatically scans those folders for applications (to get document
binding information from).
>
>
RTG> If so, then it would be possible to write a script that, run
>
as root,
>
RTG> copies the latest framework into /Library/Frameworks and
>
removes it
>
(orRTG> replaces it with a stub) in all applications that do not
>
restrict the
>
RTG> framework version (assuming this is easy to determine
>
programmatically),
>
RTG> correct?
>
>
Yeah. But then you'll have to be kind of careful, for removing one
>
application might easily render twenty others unuseable ;)
Please don't do this. You may potentially hose applications you
known nothing about. This is bad.
Scott
>
---
>
Ondra Cada
>
OCSoftware: email@hidden http://www.ocs.cz
>
private email@hidden http://www.ocs.cz/oc
>
_______________________________________________
>
cocoa-dev mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Scott Tooker
QA & Integration - Project Builder
Mac OS X Development Environment