[squeak-dev] Re: FFI question [WAS] squeakopendbx, which VM?
Andreas Raab
andreas.raab at gmx.de
Fri May 1 15:48:20 UTC 2009
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.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|