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

[David Ayers]

Richard Frith-Macdonald schrieb:
> 
> On 4 May 2006, at 09:44, David Ayers wrote:
> 
>>
>> I guess I was too terse but I would have assumed that:
>>
>> [[NSBundle bundleForLibrary:@"gnustep-base"] executablePath]
>>
>> would be what would give the expected result but indeed, this returns:
>>
>> /usr/GNUstep/System/Library/Libraries/Resources/gnustep-base/./gnu-
>> gnu-gnu/gnustep-base
>>
>> for me in a flattended configuration.
>>
>> Should this be considered a bug?
> 
> 
> While Adam is the expert on NSBundle, I think this looks like a  bug ...
> probably on a few counts:
> 
> 1. I guess in a 'flattened' configuration the 'gnu-gnu-gnu' should  not
> be in there
> 2. The actual path to the library itsself is not in the resources 
> subdirectory
> 3. I would expect the library name to be at the end of the path
> 
> Now, I hope that the oddities arise because this bundle is a special 
> case produced by a non-standard method (bundleForLibrary which does  not
> exist in OpenStep/MacOS-X).  While special case code could be
> considered a feature rather than a bug, I think it's behavior should  be
> consistent with that of other bundles!  I would have thought it  should
> return the path of the library.
> 
> I am not sure what the behavior of a flattened configuration should  be
> in general.
> 
> At present, some behavior (NSPathUtilities) seems to be controlled by 
> GNUSTEP_FLATTENED when the base library is configured, and hard coded 
> in, but other behavior (NSBundle/NSTask) ignores it and just tries to 
> find the best files available ... ie looks for files in the  unflattened
> structure and uses them in pre3ference to versions in the  flatttened
> structure.
> 
> Probably GNUSTEP_FLATTENED should be in the config file  (GNUstep.conf)
> so that it can be varied rather than being hard coded  in NSPathUtilities.
> Should NSBundle/NSTask ignore stuff in the unflatttened hierarchy if 
> running in flattened mode, or continue to use it as the preferred  version?

I think it should be ignored in the flattened case...  It seems to me
that allowing a mixed flattened/unflattened configuration is asking for
trouble.  OTOH I guess some folks could consider it a cool feature if
they could use an unflattened bundle (not build on their system) in a
flattened configuration or the other way around, assuming the
configurations match.  Yet this seems very error prone and I would not
expect anyone to maintain such a configuration at least not without
extensive continuous testing.  In fact I believe the current testing
results seem to suggest there are currently issues non flattened
configuration build, but I haven't looked into it deeply.

So, I think
1.) GNUSTEP_FLATTENED should probably go into GNUstep.conf
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).

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.

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

PPS: Please feel free to remove/adapt the test case I committed in
either way.