On 01.05.2009, at 17:48, Andreas Raab wrote:

> Bert Freudenberg wrote:
>> On 30.04.2009, at 23:55, Andreas Raab wrote:
>>> Bert Freudenberg wrote:
>>>> On 30.04.2009, at 23:22, Mariano Martinez Peck wrote:
>>>>>   However, you can of course manually do the "linking" step - in  
>>>>> the
>>>>>   ffi function declarations, use "libopendbx.so.1" as module  
>>>>> instead
>>>>>   of just "opendbx". This will then only work on Linux of course,
>>>>>   since other Unix platforms use different schemes of versioning
>>>>>   libraries.
>>>>>
>>>>>
>>>>> Indeed. That's why I don't want to change the module name.
>>>> Well, you can also automate this "pseudo-linking". When starting  
>>>> up, just patch the right module name for the current platform  
>>>> into all the FFI declarations. That's how the OpenGL FFI bindings  
>>>> in Croquet work ...
>>>
>>> The way this is done is purely for historical reasons (and an  
>>> *extremely* bad example that should not be taught to anyone). The  
>>> Right Way to do this is to have a subclass of ExternalLibrary and  
>>> implement the class-side method #moduleName along the lines of:
>>>
>>> MyLibrary class>>moduleName
>>> "Answer the module name to use for this library"
>>> Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll'].
>>> Smalltalk platformName = 'unix' ifTrue:[
>>>    "check various locations and versions"
>>>    #('/usr/lib/libMyLibrary.so'
>>>      '/usr/lib/libMyLibrary.so.1'
>>>      '/usr/lib/libMyLibrary.so.2'
>>>      '/usr/share/libMyLibrary.so.1'
>>>      '/usr/share/libMyLibrary.so.2') do:[:location|
>>>         (FileDirectory fileExists: location) ifTrue:[^location].
>>>    ].
>>>    ^self error:'MyLibrary is not installed'
>>>  ].
>>>
>>> etc.
>> Interesting. I thought the module in an FFI function declaration  
>> needed to be a literal string. How would you declare it to use  
>> MyLibrary instead?
>
> Define it in a subclass of ExternalLibrary. Functions defined in a  
> subclass of ExternalLibrary without a module: string use the  
> moduleName from the time the library is instantiated. The module:  
> string was really only intended for convenience such that one could  
> declare FFI functions where it is most convenient instead of having  
> to use ExternalLibrary subclasses.
>

That's a useful trick, thanks. Have not ever seen it before.


- Bert -