[Top][All Lists]

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

Re: GNUstep stack trace & gnustep-base.dll path

From: Richard Frith-Macdonald
Subject: Re: GNUstep stack trace & gnustep-base.dll path
Date: Fri, 5 May 2006 12:22:51 +0100

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.

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.

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

Sorry, but I currently won't have the time to implement any of this but I've added two basic test cases to out NSBundle tests. The one loading
a real NSBundle passes and the one loading the -base library fails as
currently expected.


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.

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.

reply via email to

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