frameworks Re: Introduction, and Proposed GSFH.

[Helge Hess]

Hi Nicola,

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

We always tried to map frameworks to shared libraries. Actually this 
might be the wrong approach, we should consider loading frameworks as a 
bundle since this also gives us -bundleForClass: etc !

The idea came when you said that "[frameworks are] extremely innatural 
on Windows". Actually I'm not sure about that. In Windows a shared 
library consist of a) the stub and b) the DLL. If we keep the stub and 
let it load a bundle DLL, it could work just fine. I'm pretty sure that 
it should be possible to place the framework locator code (search the 
env ...) in a "custom" DLL stub library !

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.

Maybe somebody can figure out, whether this idea is valid ...

Greetings
  Helge
--
SKYRIX Software AG     - http://www.skyrix.com
Visit us at CeBIT 2002 - hall 6 / booth H 39/1
German XML-RPC Site    - http://www.xml-rpc.de