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 <[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>
