Re: Example of a framework?

[Kaelin Colclasure]

On 1/12/02 5:59 PM, "Nicola Pero" <nicola@brainstorm.co.uk> wrote:

> 
>> I have just been reading about bundles in Apple's "Inside Mac OS X:
>> System Overview" and I am trying to get a grasp on how / whether the
>> same feature set is available from GNUstep. I am reading that an
>> application bundle can include a `Frameworks' directory containing
>> private frameworks, and that the libraries included there will always be
>> used in preference to any other when that application loads a shared
>> library. Does GNUstep implement a similar feature?
> 
> No.
> 
> Hmmm - I might modify openapp so that it will modify LD_LIBRARY_PATH to
> give the preference to libraries/frameworks found in the application
> directory if a `Libraries' or `Frameworks' directory is found there.
> 
> But in general, this is not good practice though ... shared libraries are
> meant to be shared by different applications ... reducing memory usage,
> page swapping etc ... if each application starts bundling its own copy of
> shared libraries/frameworks it needs, then that is bad.  It would be very
> silly to have different applications using different not-shared copies of
> the same shared library/framework (perhaps with trivial differences in
> versioning) ... thus depressing performance.

The Mac OS X implementation actually supports two different folders for
bundle frameworks: Frameworks and SharedFrameworks (from my recollection --
I could have these names wrong). Dynamic libraries in Frameworks are always
loaded in preference to any other for the application (tool?) that the
bundle contains. Dynamic libraries in SharedFrameworks are loaded only if
they are not superceded by newer versions elsewhere on the system.

There is also an implication that dynamic libraries in SharedFrameworks are
somehow globally visible and available to all executables. I'm not sure I
understood that bit correctly though... For one thing, it would seem to
require that some Mac OS X equivalent to `ldconfig' be run every time a
bundle is copied onto the system. And for another, it seems like it would be
too easy for accidental / malicious incompatible library collisions.

> Not sure if it's a good idea to implement this.  Anyway since it was asked
> I might implement it, but please don't use it if you can.

Well Apple's requirements clearly are that users continue to be able to
install Macintosh software by dragging and dropping a bundle onto their
system. So for Mac OS X this seems like a fairly elegant solution.

I don't presume GNUstep should pursue the same goal. GNUstep seems to be
trying to integrate with the `native' packaging systems (at least RPM and
Debian). That seems perfectly reasonable to me.

The particular application I am working on at the moment could gain some
benefit from the Mac OS X bundle behavior, because it (eventually) needs to
dynamically install bundles on demand on machines in a cluster. However, I
can certainly emulate the Mac OS X behavior myself by frobbing the helper
scripts. And I can extend GNUstep make to support this as a new type of
bundle, which will give me an excuse to add some other supporting rules to
simplify things...

>> A related confusion on my part: Are tools considered to be in a bundle
>> or not? They do use the nice wrapper script for finding the correct
>> executable for the current platform / library combination...
> 
> I'm not sure about what the question is but I'll try describing the
> situation.
> 
> An application is a gui program.  It is built as a Name.app directory
> (called the 'application main bundle'), which contains both the executable
> and other resources needed by the application to run.  As a side effect,
> to run an application you need a specific tool, `openapp', which will
> search for the appropriate Name.app directory, find the executable inside
> it, and run it.
> 
> An application bundle in gnustep can normally only contain resource files.
> Those resource files might be any file your app can use ... including
> bundles (shared libraries meant to be dynamically loaded on demand, with
> associated resource files) so for example if you build bundles for your
> application, then when you build the application you can manually move the
> built bundles into the application main bundle, you can then use those
> bundles from within the application.  In general, putting a shared library
> or a framework manually inside the application bundle has currently no
> particular effect instead ...
> 
> A tool is a non-gui program.  Probably because you want to be able to run
> tools from the command line (in the same way as you run standard unix
> utilities), tools are not built into a bundle directory - they are just
> installed as standalone executables; a wrapper script is put in place,
> which will look up the tool depending on the host / library-combo {to
> allow having multiple tool binaries for different hosts / library-combos
> installed at the same time}.  For this reason, tools traditionally have no
> associated resources/bundle.  (This is actually unfortunate :-) and in
> GNUstep we are experimenting with changing this - the idea being that each
> tool will have an associated bundle of resources, so when you install a
> tool you will be able to install resource files in the tool's bundle, and
> you can later on retrieve the bundle and so the installed resource files
> by using the GNUstep extension [NSBundle +bundleForTool:].  We're still
> evaluating this.)

For my two cents I think the idea of bundleForTool: is a good one. For one
thing it makes localizing tools possible using the same infrastructure as
applications. And for another there are plenty of examples of tools that
depend on "resources" to function.

-- Kaelin