[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
frameworks Re: Introduction, and Proposed GSFH.
From: |
Helge Hess |
Subject: |
frameworks Re: Introduction, and Proposed GSFH. |
Date: |
Fri, 01 Mar 2002 12:03:51 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 |
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
- frameworks Re: Introduction, and Proposed GSFH.,
Helge Hess <=