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 <[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> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
