Hi Daniel,
On 7 May 2015 at 04:47, Daniel Holth <
dho...@gmail.com> wrote:
> I've just tried it here with my pysdl2-cffi binding on Python 2.7 on Ubuntu
> 15.04.
Thanks for the feedback!
The PyPy version is soon ready, and I'll then write docs. The planned
release date is next week. Here's a preview of what I'd like to put
in the docs:
* I was pointed out that the current docs recommend
``ext_package=".."`` in setup.py in large projects using ffi.verify().
Remember to remove that (or to handle its effect manually) when you
are switching to ffi.set_source(). Note that the latter lets you use
a full package path, as in ``ffi.set_source("myproj._myext", ...)``.
* in addition to the distutils and setuptools solutions presented (see
blog post), you can also just produce statically and distribute the C
file (it is a completely regular C extension module then). Note that
an identical C file should be generated on any platform you run the
build script on --- but, of course, only if the way you assemble the
cdef() and the set_source() arguments is independent on the
environment. If it is not (e.g. you are checking some library version
to know if some extra cdef() lines should be included), then you
cannot distribute a static C file.
TO-DOs that will likely be done only in the next cffi version:
* the "cffi-runtime" package. For now just list "cffi" as a
setuptools dependency, both in setup_requires and install_requires.
* if you use ffi.dlopen(), you don't call any compiler, but you might
also have startup-time issues because of ``pycparser`` working its way
through a big cdef(). The idea to improve it would be to also move
the cdef() to a build.py script, but call ``ffi.set_source("module",
source=None)``. This would tell CFFI to produce a .py file instead of
a .c file. The .py file would contain a line like ``ffi =
_cffi_backend.FFI("big-string")``, where the big string is the
preprocessed binary representation of the cdef() --- a Python
equivalent to what is written in the .c file with set_source("module",
"source").
* ffi.new("xyz"), ffi.cast("xyz"), etc.: these calls always cache the
mapping from the string "xyz" to the <ctype object>. It always used
to, but in cffi < 1.0 this cache would be freed in some circumstances;
now the cache is really immortal. This might be improved in the
future, maybe by using a WeakValueDictionary-like solution. Note that
it is recommended that the type strings be constants anyway, so this
is for people who really need "int[%d]" % size. (For reference, you
can sometimes say it differently: for example, ``ffi.new("int[]",
size)``. But there is no such alternative for "int[%d][%d]" % (size1,
size2).)
A bientôt,
Armin