On Thu, Apr 22, 2010 at 1:13 PM, Marko Kocić <marko.kocic@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.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)