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

[David Ayers]

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