Well you could leave the dylib outside of the .app package for both debug and release but it wouldn't have the same ease of deployment. In the end a plug-in is just a special dylib that RB looks after putting it in the Frameworks folder. That's why they are somewhat easier to use.
Chris on 7/31/07 7:22 AM, Michael Williams at [EMAIL PROTECTED] wrote: > 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 [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>
