I absolutely understand that. Would it be possible to address my other
questions? I *want* to do the work, i simply need a solid path to pursue.
Thanks again,
Michael
------- Original message -------
From: Charles Yeomans <yeomans at desuetude dot com>
Sent: 30.7.'07, 19:00
> "Exactly" + screenshots would take a fair amount of time to put
> together for you. You might get a better response by looking for
> someone to whom you can outsource this part of your project.
>
> Charles Yeomans
>
>
> On Jul 30, 2007, at 6:47 PM, Michael Williams wrote:
>
> > 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 <npalardy at great-white-software dot com>
> >>> Reply-To: REALbasic Plugins <realbasic-
> >>> plugins at lists dot realsoftware dot com>
> >>> Date: Mon, 30 Jul 2007 11:28:30 -0600
> >>> To: REALbasic Plugins <realbasic-plugins at lists dot realsoftware dot
> >>> com>
> >>> 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>
|