Use a constant to refer to the library. Set it for different values for debugBuild and not debugBuild. I think this sort of thing is discussed in my online declares book.
Charles Yeomans On Jul 31, 2007, at 11:44 AM, [EMAIL PROTECTED] wrote: > I don't doubt that plugins are easier to *use*, but they don't seem > to be easier to *create*. I'm on a bit of a deadline (2 mths) so I > need the most > accomodating solution from beginning to end. I'm thinking that > since compiling the shared lib is easy we should go the Declare > route for now. > > Anyway, back to the discussion, what string can I set so that both > debug and production can reference the lib? If they can both use > "@executable_path" them it > would seem that there could be a single location for the lib. > > Michael > ------- Original message ------- > From: Chris Little <[EMAIL PROTECTED]> > Sent: 31.7.'07, 8:54 > >> 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 <realbasic- >>>>>>>> [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> > _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
