[pypy-commit] cffi release-1.11: hg merge default
arigo
pypy.commits at gmail.com
Sat Jan 13 05:58:16 EST 2018
Author: Armin Rigo <arigo at tunes.org>
Branch: release-1.11
Changeset: r3082:fa470f261b0d
Date: 2018-01-13 11:57 +0100
http://bitbucket.org/cffi/cffi/changeset/fa470f261b0d/
Log: hg merge default
diff --git a/c/_cffi_backend.c b/c/_cffi_backend.c
--- a/c/_cffi_backend.c
+++ b/c/_cffi_backend.c
@@ -2,7 +2,7 @@
#include <Python.h>
#include "structmember.h"
-#define CFFI_VERSION "1.11.3"
+#define CFFI_VERSION "1.11.4"
#ifdef MS_WIN32
#include <windows.h>
diff --git a/c/test_c.py b/c/test_c.py
--- a/c/test_c.py
+++ b/c/test_c.py
@@ -12,7 +12,7 @@
# ____________________________________________________________
import sys
-assert __version__ == "1.11.3", ("This test_c.py file is for testing a version"
+assert __version__ == "1.11.4", ("This test_c.py file is for testing a version"
" of cffi that differs from the one that we"
" get from 'import _cffi_backend'")
if sys.version_info < (3,):
diff --git a/cffi/__init__.py b/cffi/__init__.py
--- a/cffi/__init__.py
+++ b/cffi/__init__.py
@@ -4,8 +4,8 @@
from .api import FFI
from .error import CDefError, FFIError, VerificationError, VerificationMissing
-__version__ = "1.11.3"
-__version_info__ = (1, 11, 3)
+__version__ = "1.11.4"
+__version_info__ = (1, 11, 4)
# The verifier module file names are based on the CRC32 of a string that
# contains the following version number. It may be older than __version__
diff --git a/cffi/_cffi_include.h b/cffi/_cffi_include.h
--- a/cffi/_cffi_include.h
+++ b/cffi/_cffi_include.h
@@ -8,37 +8,19 @@
the same works for the other two macros. Py_DEBUG implies them,
but not the other way around.
- Issue #350: more mess: on Windows, with _MSC_VER, we have to define
- Py_LIMITED_API even before including pyconfig.h. In that case, we
- guess what pyconfig.h will do to the macros above, and check our
- guess after the #include.
+ Issue #350 is still open: on Windows, the code here causes it to link
+ with PYTHON36.DLL (for example) instead of PYTHON3.DLL. A fix was
+ attempted in 164e526a5515 and 14ce6985e1c3, but reverted: virtualenv
+ does not make PYTHON3.DLL available, and so the "correctly" compiled
+ version would not run inside a virtualenv. We will re-apply the fix
+ after virtualenv has been fixed for some time. For explanation, see
+ issue #355. For a workaround if you want PYTHON3.DLL and don't worry
+ about virtualenv, see issue #350.
*/
#if !defined(_CFFI_USE_EMBEDDING) && !defined(Py_LIMITED_API)
-# ifdef _MSC_VER
-# if !defined(_DEBUG) && !defined(Py_DEBUG) && !defined(Py_TRACE_REFS) && !defined(Py_REF_DEBUG)
-# define Py_LIMITED_API
-# endif
-# include <pyconfig.h>
- /* sanity-check: Py_LIMITED_API will cause crashes if any of these
- are also defined. Normally, the Python file PC/pyconfig.h does not
- cause any of these to be defined, with the exception that _DEBUG
- causes Py_DEBUG. Double-check that. */
-# ifdef Py_LIMITED_API
-# if defined(Py_DEBUG)
-# error "pyconfig.h unexpectedly defines Py_DEBUG but _DEBUG is not set"
-# endif
-# if defined(Py_TRACE_REFS)
-# error "pyconfig.h unexpectedly defines Py_TRACE_REFS"
-# endif
-# if defined(Py_REF_DEBUG)
-# error "pyconfig.h unexpectedly defines Py_REF_DEBUG"
-# endif
-# endif
-# else
-# include <pyconfig.h>
-# if !defined(Py_DEBUG) && !defined(Py_TRACE_REFS) && !defined(Py_REF_DEBUG)
-# define Py_LIMITED_API
-# endif
+# include <pyconfig.h>
+# if !defined(Py_DEBUG) && !defined(Py_TRACE_REFS) && !defined(Py_REF_DEBUG)
+# define Py_LIMITED_API
# endif
#endif
diff --git a/cffi/_embedding.h b/cffi/_embedding.h
--- a/cffi/_embedding.h
+++ b/cffi/_embedding.h
@@ -247,7 +247,7 @@
if (f != NULL && f != Py_None) {
PyFile_WriteString("\nFrom: " _CFFI_MODULE_NAME
- "\ncompiled with cffi version: 1.11.3"
+ "\ncompiled with cffi version: 1.11.4"
"\n_cffi_backend module: ", f);
modules = PyImport_GetModuleDict();
mod = PyDict_GetItemString(modules, "_cffi_backend");
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -38,7 +38,7 @@
# General information about the project.
project = u'CFFI'
-copyright = u'2012-2015, Armin Rigo, Maciej Fijalkowski'
+copyright = u'2012-2018, Armin Rigo, Maciej Fijalkowski'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
@@ -47,7 +47,7 @@
# The short X.Y version.
version = '1.11'
# The full version, including alpha/beta/rc tags.
-release = '1.11.3'
+release = '1.11.4'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
diff --git a/doc/source/embedding.rst b/doc/source/embedding.rst
--- a/doc/source/embedding.rst
+++ b/doc/source/embedding.rst
@@ -279,12 +279,24 @@
Troubleshooting
---------------
-The error message
+* The error message
cffi extension module 'c_module_name' has unknown version 0x2701
-means that the running Python interpreter located a CFFI version older
-than 1.5. CFFI 1.5 or newer must be installed in the running Python.
+ means that the running Python interpreter located a CFFI version older
+ than 1.5. CFFI 1.5 or newer must be installed in the running Python.
+
+* On PyPy, the error message
+
+ debug: pypy_setup_home: directories 'lib-python' and 'lib_pypy' not
+ found in pypy's shared library location or in any parent directory
+
+ means that the ``libpypy-c.so`` file was found, but the standard library
+ was not found from this location. This occurs at least on some Linux
+ distributions, because they put ``libpypy-c.so`` inside ``/usr/lib/``,
+ instead of the way we recommend, which is: keep that file inside
+ ``/opt/pypy/bin/`` and put a symlink to there from ``/usr/lib/``.
+ The quickest fix is to do that change manually.
Issues about using the .so
diff --git a/doc/source/goals.rst b/doc/source/goals.rst
new file mode 100644
--- /dev/null
+++ b/doc/source/goals.rst
@@ -0,0 +1,62 @@
+Goals
+-----
+
+The interface is based on `LuaJIT's FFI`_, and follows a few principles:
+
+* The goal is to call C code from Python without learning a 3rd language:
+ existing alternatives require users to learn domain specific language
+ (Cython_, SWIG_) or API (ctypes_). The CFFI design requires users to know
+ only C and Python, minimizing the extra bits of API that need to be learned.
+
+* Keep all the Python-related logic in Python so that you don't need to
+ write much C code (unlike `CPython native C extensions`_).
+
+* The preferred way is to work at the level of the API (Application
+ Programming Interface): the C compiler is called from the declarations
+ you write to validate and link to the C language constructs.
+ Alternatively, it is also possible to work at the ABI level
+ (Application Binary Interface), the way ctypes_ work.
+ However, on non-Windows platforms, C libraries typically
+ have a specified C API but not an ABI (e.g. they may
+ document a "struct" as having at least these fields, but maybe more).
+
+* Try to be complete. For now some C99 constructs are not supported,
+ but all C89 should be, including macros (and including macro "abuses",
+ which you can `manually wrap`_ in saner-looking C functions).
+
+* Attempt to support both PyPy and CPython, with a reasonable path
+ for other Python implementations like IronPython and Jython.
+
+* Note that this project is **not** about embedding executable C code in
+ Python, unlike `Weave`_. This is about calling existing C libraries
+ from Python.
+
+.. _`LuaJIT's FFI`: http://luajit.org/ext_ffi.html
+.. _`Cython`: http://www.cython.org
+.. _`SWIG`: http://www.swig.org/
+.. _`CPython native C extensions`: http://docs.python.org/extending/extending.html
+.. _`native C extensions`: http://docs.python.org/extending/extending.html
+.. _`ctypes`: http://docs.python.org/library/ctypes.html
+.. _`Weave`: http://wiki.scipy.org/Weave
+.. _`manually wrap`: overview.html#abi-versus-api
+
+Get started by reading `the overview`__.
+
+.. __: overview.html
+
+
+Comments and bugs
+-----------------
+
+The best way to contact us is on the IRC ``#pypy`` channel of
+``irc.freenode.net``. Feel free to discuss matters either there or in
+the `mailing list`_. Please report to the `issue tracker`_ any bugs.
+
+As a general rule, when there is a design issue to resolve, we pick the
+solution that is the "most C-like". We hope that this module has got
+everything you need to access C code and nothing more.
+
+--- the authors, Armin Rigo and Maciej Fijalkowski
+
+.. _`issue tracker`: https://bitbucket.org/cffi/cffi/issues
+.. _`mailing list`: https://groups.google.com/forum/#!forum/python-cffi
diff --git a/doc/source/index.rst b/doc/source/index.rst
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -6,13 +6,10 @@
code from Python, based on C-like declarations that you can often
copy-paste from header files or documentation.
-* Goals_
-
- * `Comments and bugs`_
-
.. toctree::
:maxdepth: 2
+ goals
whatsnew
installation
overview
@@ -22,65 +19,4 @@
embedding
-Goals
------
-The interface is based on `LuaJIT's FFI`_, and follows a few principles:
-
-* The goal is to call C code from Python without learning a 3rd language:
- existing alternatives require users to learn domain specific language
- (Cython_, SWIG_) or API (ctypes_). The CFFI design requires users to know
- only C and Python, minimizing the extra bits of API that need to be learned.
-
-* Keep all the Python-related logic in Python so that you don't need to
- write much C code (unlike `CPython native C extensions`_).
-
-* The preferred way is to work at the level of the API (Application
- Programming Interface): the C compiler is called from the declarations
- you write to validate and link to the C language constructs.
- Alternatively, it is also possible to work at the ABI level
- (Application Binary Interface), the way ctypes_ work.
- However, on non-Windows platforms, C libraries typically
- have a specified C API but not an ABI (e.g. they may
- document a "struct" as having at least these fields, but maybe more).
-
-* Try to be complete. For now some C99 constructs are not supported,
- but all C89 should be, including macros (and including macro "abuses",
- which you can `manually wrap`_ in saner-looking C functions).
-
-* Attempt to support both PyPy and CPython, with a reasonable path
- for other Python implementations like IronPython and Jython.
-
-* Note that this project is **not** about embedding executable C code in
- Python, unlike `Weave`_. This is about calling existing C libraries
- from Python.
-
-.. _`LuaJIT's FFI`: http://luajit.org/ext_ffi.html
-.. _`Cython`: http://www.cython.org
-.. _`SWIG`: http://www.swig.org/
-.. _`CPython native C extensions`: http://docs.python.org/extending/extending.html
-.. _`native C extensions`: http://docs.python.org/extending/extending.html
-.. _`ctypes`: http://docs.python.org/library/ctypes.html
-.. _`Weave`: http://wiki.scipy.org/Weave
-.. _`manually wrap`: overview.html#abi-versus-api
-
-Get started by reading `the overview`__.
-
-.. __: overview.html
-
-
-Comments and bugs
------------------
-
-The best way to contact us is on the IRC ``#pypy`` channel of
-``irc.freenode.net``. Feel free to discuss matters either there or in
-the `mailing list`_. Please report to the `issue tracker`_ any bugs.
-
-As a general rule, when there is a design issue to resolve, we pick the
-solution that is the "most C-like". We hope that this module has got
-everything you need to access C code and nothing more.
-
---- the authors, Armin Rigo and Maciej Fijalkowski
-
-.. _`issue tracker`: https://bitbucket.org/cffi/cffi/issues
-.. _`mailing list`: https://groups.google.com/forum/#!forum/python-cffi
diff --git a/doc/source/installation.rst b/doc/source/installation.rst
--- a/doc/source/installation.rst
+++ b/doc/source/installation.rst
@@ -53,13 +53,13 @@
* https://pypi.python.org/pypi/cffi
-* Checksums of the "source" package version 1.11.3:
+* Checksums of the "source" package version 1.11.4:
- - MD5: 3d263ec84bb9ad08e0edf2d21312fa1e
+ - MD5: ...
- - SHA: 26a73cc075064cc7cd59ec6c58ca0684d16c4ece
+ - SHA: ...
- - SHA256: 150708ce9e417858f9a4056b5f364d8c7077fd979b9e35307c2d8a4a8e991fd2
+ - SHA256: ...
* Or grab the most current version from the `Bitbucket page`_:
``hg clone https://bitbucket.org/cffi/cffi``
diff --git a/doc/source/whatsnew.rst b/doc/source/whatsnew.rst
--- a/doc/source/whatsnew.rst
+++ b/doc/source/whatsnew.rst
@@ -2,6 +2,15 @@
What's New
======================
+v1.11.4
+=======
+
+* Windows: reverted linking with ``python3.dll``, because
+ virtualenv does not make this DLL available to virtual environments
+ for now. See `Issue #355`_.
+
+.. _`Issue #355`: https://bitbucket.org/cffi/cffi/issues/355/
+
v1.11.3
=======
@@ -95,8 +104,11 @@
.. __: http://bugs.python.org/issue31105
+Older Versions
+==============
+
v1.10.1
-=======
+-------
(only released inside PyPy 5.8.0)
@@ -107,7 +119,7 @@
v1.10
-=====
+-----
* Issue #295: use calloc() directly instead of
PyObject_Malloc()+memset() to handle ffi.new() with a default
@@ -169,7 +181,7 @@
v1.9
-====
+----
* Structs with variable-sized arrays as their last field: now we track
the length of the array after ``ffi.new()`` is called, just like we
@@ -204,7 +216,7 @@
v1.8.3
-======
+------
* When passing a ``void *`` argument to a function with a different
pointer type, or vice-versa, the cast occurs automatically, like in C.
@@ -217,7 +229,7 @@
v1.8.2
-======
+------
* Issue #283: fixed ``ffi.new()`` on structures/unions with nested
anonymous structures/unions, when there is at least one union in
@@ -226,7 +238,7 @@
v1.8.1
-======
+------
* CPython 3.x: experimental: the generated C extension modules now use
the "limited API", which means that, as a compiled .so/.dll, it should
@@ -241,7 +253,7 @@
v1.8
-====
+----
* Removed the restriction that ``ffi.from_buffer()`` cannot be used on
byte strings. Now you can get a ``char *`` out of a byte string,
@@ -255,7 +267,7 @@
v1.7
-====
+----
* ``ffi.gc(p, None)`` removes the destructor on an object previously
created by another call to ``ffi.gc()``
@@ -284,7 +296,7 @@
v1.6
-====
+----
* `ffi.list_types()`_
@@ -307,13 +319,13 @@
v1.5.2
-======
+------
* Fix 1.5.1 for Python 2.6.
v1.5.1
-======
+------
* A few installation-time tweaks (thanks Stefano!)
@@ -325,7 +337,7 @@
v1.5.0
-======
+------
* Support for `using CFFI for embedding`__.
@@ -333,13 +345,13 @@
v1.4.2
-======
+------
Nothing changed from v1.4.1.
v1.4.1
-======
+------
* Fix the compilation failure of cffi on CPython 3.5.0. (3.5.1 works;
some detail changed that makes some underscore-starting macros
@@ -349,7 +361,7 @@
v1.4.0
-======
+------
* A `better way to do callbacks`__ has been added (faster and more
portable, and usually cleaner). It is a mechanism for the
@@ -390,7 +402,7 @@
v1.3.1
-======
+------
* The optional typedefs (``bool``, ``FILE`` and all Windows types) were
not always available from out-of-line FFI objects.
@@ -406,7 +418,7 @@
v1.3.0
-======
+------
* Added `ffi.memmove()`_.
@@ -441,13 +453,13 @@
v1.2.1
-======
+------
Nothing changed from v1.2.0.
v1.2.0
-======
+------
* Out-of-line mode: ``int a[][...];`` can be used to declare a structure
field or global variable which is, simultaneously, of total length
@@ -500,14 +512,14 @@
v1.1.2
-======
+------
* ``ffi.gc()``: fixed a race condition in multithreaded programs
introduced in 1.1.1
v1.1.1
-======
+------
* Out-of-line mode: ``ffi.string()``, ``ffi.buffer()`` and
``ffi.getwinerror()`` didn't accept their arguments as keyword
@@ -525,7 +537,7 @@
v1.1.0
-======
+------
* Out-of-line API mode: we can now declare integer types with
``typedef int... foo_t;``. The exact size and signedness of ``foo_t``
@@ -558,13 +570,13 @@
v1.0.3
-======
+------
* Same as 1.0.2, apart from doc and test fixes on some platforms.
v1.0.2
-======
+------
* Variadic C functions (ending in a "..." argument) were not supported
in the out-of-line ABI mode. This was a bug---there was even a
@@ -574,7 +586,7 @@
v1.0.1
-======
+------
* ``ffi.set_source()`` crashed if passed a ``sources=[..]`` argument.
Fixed by chrippa on pull request #60.
@@ -587,7 +599,7 @@
v1.0.0
-======
+------
* The main news item is out-of-line module generation:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -186,7 +186,7 @@
`Mailing list <https://groups.google.com/forum/#!forum/python-cffi>`_
""",
- version='1.11.3',
+ version='1.11.4',
packages=['cffi'] if cpython else [],
package_data={'cffi': ['_cffi_include.h', 'parse_c_type.h',
'_embedding.h', '_cffi_errors.h']}
More information about the pypy-commit
mailing list