discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Example of a framework?


From: Nicola Pero
Subject: Re: Example of a framework?
Date: Sun, 13 Jan 2002 01:59:48 +0000 (GMT)

> 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.

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.


> 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.)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]