Yup, I'm familiar with the contents of a ".app". So, there's no way
in RB to have the "dylib" referenced universally, and then compiled
in, without having to account for at least two locations? No one-
stop-drop?
Michael
On Jul 31, 2007, at 7:05 AM, Chris Little wrote:
> I think I understand your confusion now. A Mac application is
> actually a
> folder tree. If you right-click on an app and select Show Package
> Contents
> you can see what I mean. If you do this for an RB app an expand the
> tree you
> will see the folder containing the actual executable plus a Frameworks
> folder. If you want to use declares then for debug builds you put
> the dylib
> in the same folder as the app package and the path constant starts
> from the
> real executable file and walks up the tree to the dylib. For the
> release
> build you would open the app package and copy the dylib into the
> Frameworks
> folder. The release path constant reflects this.
>
> Chris
>
> on 7/30/07 10:34 PM, Michael Williams at lists at mgreg dot com wrote:
>
>> Frank,
>>
>> Thanks, that's exactly what I was looking for (although I must say
>> I'm *still* confused as to how "@executable_path" still allows it to
>> work even if the library is in the system domain). Now I guess it's
>> on to getting to know the library. If you guys have any other
>> suggestions, pointers, or 'gotchas' please keep 'em comin.
>>
>> Thanks again to everyone for their time and input.
>>
>> Regards,
>> Michael
>>
>> On Jul 30, 2007, at 7:06 PM, Frank Condello wrote:
>>
>>> This becomes tedious if you have, say several hundred declares ;) If
>>> you use a framework, you can use a single constant defined globally
>>> as:
>>>
>>> "@executable_path/../Frameworks/LibName.framework/LibName"
>>>
>>> Then things will "just work" regardless if the framework is
>>> installed
>>> in the system domain, user domain (for debug builds), or in the
>>> application bundle (for release builds). I add checks to release
>>> builds to ensure the framework has actually been copied to the
>>> bundle
>>> however, to ensure I don't distribute a broken standalone app.
>>>
>>> To get slightly back on topic, I'd recommend declares over a plugin
>>> whenever possible. Declares tend to be much easier to maintain and
>>> extend over time, especially if the library binaries are readily
>>> available.
>>>
>>> Frank.
>>> <http://developer.chaoticbox.com/>
>>>
>>> On 30-Jul-07, at 6:19 PM, Dave Addey wrote:
>>>
>>>> I do this in a dual way - using one location for debug, and another
>>>> for the
>>>> built app:
>>>>
>>>> #if DebugBuild
>>>> Const kHIDLib = "@executable_path/../../../
>>>> libHIDUtilities.dylib"
>>>> #else
>>>> Const kHIDLib = "@executable_path/../Frameworks/
>>>> libHIDUtilities.dylib"
>>>> #endif
>>>>
>>>> Declare Function HIDGetFirstDeviceElement Lib kHIDLib
>>>> (inDevicePtr as
>>>> integer, inElementTypeMask as integer) as integer
>>>>
>>>> When I have built the final app, I copy the dylib inside the bundle
>>>> and the
>>>> non-debugbuild line above finds the dylib. When I am running in
>>>> debug, the
>>>> code above looks for the same dylib, *alongside* the debug app.
>>>> This means
>>>> I don't have to build the app to test every time, and can still run
>>>> in RB's
>>>> debug mode.
>>>>
>>>> Dave.
>>>>
>>>>> From: Norman Palardy <npalardy at great-white-software dot com>
>>>>> Reply-To: REALbasic Plugins <realbasic-
>>>>> plugins at lists dot realsoftware dot com>
>>>>> Date: Mon, 30 Jul 2007 11:28:30 -0600
>>>>> To: REALbasic Plugins <realbasic-plugins at lists dot realsoftware dot
>>>>> com>
>>>>> Subject: Re: Incorporating existing C/C++ libraries into an RB
>>>>> Project. . .?
>>>>>
>>>>>
>>>>> On 30-Jul-07, at 11:16 AM, Michael Williams wrote:
>>>>>
>>>>>> Gotcha,
>>>>>>
>>>>>> So you're recommending going the "dylib" route as opposed to the
>>>>>> plugin route? What kind of recommendations have you for actually
>>>>>> distributing the "dylib"? Someone mentioned actually placing the
>>>>>> "dylib" in the RB package, I'm not terribly familiar with that
>>>>>> process, nor how to reference a self-contained library.
>>>>>>
>>>>>> Michael
>>>>>
>>>>>
>>>>> you can use a "special" name for a dylib in OS X that permits
>>>>> you to
>>>>> locate it relative to the actual executable
>>>>>
>>>>> instead of
>>>>>
>>>>> Soft declare sub/function name lib "lib name" ....
>>>>>
>>>>> use
>>>>> Soft Declare Sub/function name Lib "@executable_path/../
>>>>> Frameworks/lib name" ....
>>>>>
>>>>> and then in the OS X version you copy your dylib into the
>>>>> FrameWorks
>>>>> folder in the package
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|