The problem is that REALbasic does not have a way to add a library to
the application bundle it builds for debugging. So for debug apps,
you have to fake it.
Charles Yeomans
On Jul 31, 2007, at 7:22 AM, Michael Williams 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 lists at mgreg dot com 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 <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>
|