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 [EMAIL PROTECTED] 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 <[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>
