Re: frameworks Re: Introduction, and Proposed GSFH.

[Nicola Pero]

> Hi Nicola,
> 
> just had an idea about framework implementation after reading your mail 
> ;-) It's not completly thought out, but maybe you jump in ...

Yep - thanks - it's very interesting.
 

> OK, we don't really care about Windows, so let's get back to Unix. The 
> framework is going to be compiled as a usual bundle (possibly with 
> additions for bundle versioning).
> So this would work just fine, but the "advantage" of frameworks is, that 
> they are explicitly linked with a tool/app/.. So my idea would be to 
> generate either a stub library or to generate stub code, which loads the 
> bundle eg in some kind of _start callback. Eg if gstep-make sees a 
> "blah_FRAMEWORKS=-framework Blah" it could generate a small .m file 
> which contains something like:
>    [[NSBundle bundleWithPath:GSLocateFw(@"Blah")] load];
> or we could call that in NSProcessInfo initialization.

But sure gnustep-base can't be a framework then :-) since you are using
gnustep-base code to load frameworks dynamically :-)

But yes - you might basically implement your custom dynamic linker for
frameworks inside gnustep-base.  Assuming that the local platform allows
you to dynamically load bundles, then you could search the required
directories manually for frameworks, and load the shared object wherever
from inside the framework directory.  This would work without the symbolic
links (it wouldn't work at all if you can't load bundles).

I suppose to have the loading code executed, you would either compile into
the tool/application/xxx using the framework some little code or ... well
possibly studying the linker/object format you might find a nice
platform-dependent way of storing into the executable a list of frameworks
it was linked against (version of course included), and then gnustep-base
would examine that list at tool startup (and when it loads a bundle, it
must be able to read the list attached to the bundle) and load the
required frameworks using the built-in dynamical linker.

So, 

 - gnustep-base would not be a framework, but must remain a dynamical
   library;

 - you need to implement code in gnustep-base to look up for the
   frameworks, and load them (a little dynamic linker basicaly, but
   easy);

 - you need to study a bit the situation and find the least disturbing
   way of saving into each object file the list of frameworks it was
   linked against (possibly with the version :-).

This would possibly be more difficult to port - than the current framework
stuff - or if done very carefully might actually be easier :-), probably
more satisfactory.


I'm personally perfectly happy with shared libraries and bundles, but if
some framework fan wants to implement this scheme, we accept patches :-)