Use a constant to refer to the library. Set it for different values
for debugBuild and not debugBuild. I think this sort of thing is
discussed in my online declares book.
Charles Yeomans
On Jul 31, 2007, at 11:44 AM, lists at mgreg dot com wrote:
> 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 <cslittle at mac dot com>
> 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 lists at mgreg dot com 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>
|