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 <[EMAIL PROTECTED]>
>> Reply-To: REALbasic Plugins <realbasic-
>> [EMAIL PROTECTED]>
>> Date: Mon, 30 Jul 2007 11:28:30 -0600
>> To: REALbasic Plugins <[email protected]>
>> 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>
