Richard Frith-Macdonald schrieb: > > On 5 May 2006, at 10:02, David Ayers wrote: > >> So, I think >> 1.) GNUSTEP_FLATTENED should probably go into GNUstep.conf > > > I'm no longer so sure ... do we want it to change at runtime or be > fixed when the library is built? The architecture/operating-system/ > library-combo *must* be fixed at compile time, so I'm not sure whether > it mmakes much sense to extend the flattened stuff to be changable at > runtime.
Indeed. I was confused. >> 2.) we should try to implement NSBundle/NSTask via NSPathUtilities (with >> potentially new GSExtensionFunctions). >> 3.) deprecate the misleading objc_ functions in GNUstep (misleading in >> the sense that the names suggest that this is libobjc API). > > > Well, they are private/internal API and don't appear in the headers > afaik ... so we don't need to deprecate them, but can change them. Fine by me. >> Also it maybe a good idea to look into whether we want the >> implementation of -executablePath to make assumptions about the >> directory layout for known bundle types or whether we should only use >> those as a fallback when the dladdr mechanisms (or windows equivalent) >> fail or do not exist. > > > A good fallback mechanism would be nice ... but I don't know how it > would work, and don't have time to look at it now. I've coded on the > assumption that the dladdr type mechanism will work, and if we find > future situations where it won't we would need to make any fallback > mechanism a plugin replacement for the dladdr stuff > (objc_get_symbol_path()). Well the current "we have a bundle (including path) of a certain type and we know -make should be installing the executable here so let's see if we find the executable" approach that was being used, was the "fallback" that I was referring to /if/ the dladdr mechanism fails. But, sure a better mechanism would be great. >> PS: About having -executablePath return nil for bundleWithLibrary: ... >> Well I guess that's feasible but in the spirit of GNUstep "finding a >> technically superior solution" (paraphrased) I think there would be no >> harm done if someone did contribute code to return the path to the >> "corresponding" executable /if it can be determined/. (In the static >> linking case I think it would be legitimate to either return nil or the >> path to the main executable. But in any case we need to update the >> documentation to reflect the limitations (but note that superior >> implementations are welcome). > > > I've done those updates to get it working as best I can. In general I > think we need the Info.plist in the library resources area to specify > NSPrincipalClass so we can associate that class with the library bundle > and determine the path to the library itsself from the class > information at runtime. > > Perhaps we could extend that with a mechanism in Info.plist to specify > all the classes in the library ... then NSBundle could read that and > associate all the classes with the library. The make system could have > an option to fill in that Info.plist information automatically when a > library is built/installed. Well I would actually consider the "tried and tested" mechanism that I believe we are using for frameworks... i.e. create a specially mangled class for this purpose specifically. This would also work with library projects which do not contain any classes. > I also added a mechanism so that +bundleForClass: will, in additiond to > searching for the class in all loaded bundles, create a library bundle > if the class resides in a dynamic library and return the main bundle if > the class resides in the program executable. Nice! Cheers, David _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
