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?

- Bert -