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

[Richard Frith-Macdonald]

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.
>
> Cheers,
> David
>
>
> 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.