Re: +[NSBundle mainBundle] broken for tools?

[Richard Frith-Macdonald]

On Monday, July 21, 2003, at 01:20 PM, Roland Schwingel wrote:

> Hi...
>
> If one wants to run a tool and +[NSBundle mainBundle] is called it 
> will run into serious trouble...
>
> Imagine you have a tool which fullpath is
> /imagine/your/favourite/path/tool
>
> +[NSBundle mainBundle] first generates
> toolName = tool
> path = /imagine/your/favourite/path
>
> Afterwards it checks path for having a .app/.debug etc suffix. When 
> this suffix is not present (look above) the tool is declared to be a 
> non-application (isApplication = NO). And now the bug happens.
>
>    if (isApplication == NO)
>    {
>      path = [path stringByAppendingPathComponent: @"Resources"];
>      path = [path stringByAppendingPathComponent: toolName];
>     }
>
> So path is now: /imagine/your/favourite/path/Resources/tool which is 
> then used for [_mainBundle initWithPath:path] which fails.... So if 
> you have a standalone tool, do you really need this 
> directory-structure for it??? It looks a bit odd to me....

Well, I know why this change was made ... the intention was to
support tool specific resources, so the bundle path is changed
to point to a per-tool subdirectory.  This is a great improvement
on the old behavior, but as you point out, it doesn't work properly
when a tool has no resources ... and that's the common case.

One possibility is to check for existence of the resources directory and
only use it if it exists ... but I don't like that because it's not 
consistent for
all tools.

So, the best idea I could think of is to keep the old bundle directory
(ie the directory containing the executable), but have the code which
determines resource paths know about this special case, and look in
the 'Resources/toolname/Resources'  subdirectory rather than simply
the 'Resources' subdirectory.

I have a patch that attempts to do this ... what do people think?

NSBundle.m.diff
Description: Binary data