On 31-Jul-07, at 11:14 AM, [EMAIL PROTECTED] wrote:
> I guess, before saying "arbitrary", I should ask what
> "@executable_path" resolves to. Per a previous post it was used for
> both debug and production constants.
> So, if, in fact, it resolves to the same place, then the need for a
> different location does seem arbitrary.
Not arbitrary at all. It does resolve to the same place.
The issue is not one of WHERE @executable_path resolves to but the
fact that when you hit DEBUG in the RB IDE you have no way to tell RB
to automatically put your dylib in the right spot for the debug run.
You COULD insert a
#if debugBuild
msgbox "copy the dylib"
#endif
in the app open event and then manually place the dylib in the same
spot as it would be located in a final build
However this does mess with the normal "opening" of your application
and would be different than a built version.
So you have a couple choices
1) use a different location for debug builds because then you do
not have to interrupt the normal opening of your app
2) use the same location but interrupt your app's open event as
described
3) run a script as part of your app open that copies the dylib from
one spot into the same location as it would be in a built app
> So, how does linux handle the same issue?
Linux works differently
It has no concept of packages and no ability to have the dylibs in an
app package like OS X.
An OS X app can be relocated anywhere a user chooses using this
mechanism and can often be installed "properly" by a simple copy
because the dylibs are actually IN the folder hierarchy represented
by the app.
Linux and Windows have nothing similar
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
