[Ecls-list] Preferred FFI bindings

[Juan Jose Garcia-Ripoll]

On Thu, Apr 22, 2010 at 1:13 PM, Marko Kocić <marko.kocic at gmail.com> wrote:

> I see that ECL itself includes both low-level clines c-inline and UFFI
> approach, and that CFFI also supports ECL. What are performance
> limitations when dealing with different bindings approaches.
>

I do not know the status of the current CFFI backend. Last time I saw it
allowed both to use a backedn based on c-inline and a backend based on the
dynamic foreign function interface -- but unfortunately the only way to
choose was to remove :dffi from the features --.  I find it is a good
starting point because it does not have that many dependencies (alexandria,
babel and trivial-features) and it may be easier to get something up and
running. Besides, you may find some time to improve the backend? ;-)


> I'm mainly interested in SDL right now. I would like to avoid
> lispbuilder-sdl because of long dependency chain (and it doesn't
> compile with ECL right now)


Yes, I say the report. I will look into it.


> and to create low level bindings, since I
> would like to learn more about SDL in the process. Since app I have in
> plan is a small one, I'd also like to avoid CFFI as it also has long
> list of dependencies unless there is compelling reason to use it
> instead of UFFI/FFI.
>

I cannot argue against this: direct use of ECL's FFI will produce much
leaner code, not depending on an existing CFFI library -- it would be
interesting to get CFFI produce standalone code: that is code that does not
depend on CFFI being there to run.


> Also, is there a way to automatically generate FFI bindings by
> providing h file, or it has to be done manually?
>

Not right now, but it should not be difficult to get the output of
cffi-grovel and automatically translate it to ECL's FFI.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100422/cf6dfc18/attachment.html>