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