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