Alright, but I'm still a bit sketchy on actually placing the "framework". Basically what I want to know is where *exactly* (screenshots might be helpful) do I place all files at any point in time so as to both test and distribute? And, why is it necessary to have different spots?
Also, a bit of a side question as I lack sufficient knowledge to ask the proper question, but what are the general mechanisms by which to extract existing functions from C-source? How does Visual Studio vs XCODE vs GCC handle "method extraction"? "Method extraction" meaning a nice sidebar (e.g. Eclipse), or printout of existing functions/ methods. It would be nice to have a handy-dandy list so as to look at what portions I wish to Declare. Thanks, Michael On Jul 30, 2007, 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> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
