On 5 May 2006, at 08:21, Richard Frith-Macdonald wrote:
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.
After looking at bundleForLibrary: some more ... I'm fairly convinced
that it should in fact return nil for -executablePath
That's because I'm now much clearer on what this extension does ...
it provides a resource bundle for a library linked in to the
executable, but it is nothing to do with the code in the library.
The bundle is based solely on the library name, and may be used for -
1. a dynamically linked library (the obvious case)
2. a statically linked library (so the original library may not exist
on the running system!)
3. a library which is not even linked in to the executable ... if you
want to use its resources but not the code.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
