This backports changes from pypy-devel. Although that port has not gone
through standard QA, there have not been any complaints in the months that
it has been available under pypy-devel.
Changes:
* various: migrate USE_BZIP2 to USES=tar:bzip2
* various: migrate USE_XZ to USES=tar:xz
* multimedia/py-ffmpeg: add and prefer github (GH) as master site
* ports-mgmt/portbuilder: specify license as BSD2CLAUSE (instead of just BSD)
Most ports are updated infrequently so a single batch commit is preferred over
collating changes per port.
Also, require a modern compiler that can handle c11. Although this is
not strictly required (just about any C compiler would do) the base GCC
compiler has a memory bug and thus cannot reasonably compile the ports.
Be more aggresive in cleaning up temporary directories that pypy leaves
behind in the copied directories (files and directories in __pycache__).
Only .so and .pyc should be left behind in those __pycache__ directories
and no subdirectories.
Also remove the manual requirement for building lang/pypy. Redports
successfully built lang/pypy3-devel (with leftovers) in 19 hours.
Reported by: Redports
pypy-devel is intended as a staging ground for beta releases and - while
no beta releases are available - snapshots of pypy default branch.
While introducing pypy-devel to build logic has been reworked to better
accomodate pypy3. The lib-python/2.7 and lib_pypy folders are not renamed
after extraction (with only symbolic links used to emulate the structure).
PyPy still expects the standard structure and the symbolic links satisfy
this change.
The devel port was requested by mva@ to better support commercial clients.
Changes:
- Rename the binary, include and library to pypy-2.1 (recommended by mva@).
This is in preparation to introduce PyPy3 (PyPy implementing Python 3.2)
Highlights:
* JIT support for ARM, architecture versions 6 and 7, hard- and soft-float ABI
* Stacklet support for ARM
* Support for os.statvfs and os.fstatvfs on unix systems
* Improved logging performance
* Faster sets for objects
* Interpreter improvements
* During packaging, compile the CFFI based TK extension
* Pickling of numpy arrays and dtypes
* Subarrays for numpy
* Bugfixes to numpy
* Bugfixes to cffi and ctypes
* Bugfixes to the x86 stacklet support
* Fixed issue 1533: fix an RPython-level OverflowError for
space.float_w(w_big_long_number). https://bugs.pypy.org/issue1533
* Fixed issue 1552: GreenletExit should inherit from BaseException.
https://bugs.pypy.org/issue1552
* Fixed issue 1537: numpypy __array_interface__ https://bugs.pypy.org/issue1537
* Fixed issue 1238: Writing to an SSL socket in PyPy sometimes failed with a
"bad write retry" message. https://bugs.pypy.org/issue1238
Highlights:
* Support for os.statvfs and os.fstatvfs on unix systems.
* Fixed issue 1533: fix an RPython-level OverflowError for
space.float_w(w_big_long_number).
* Fixed issue 1552: GreenletExit should inherit from BaseException.
* Fixed issue 1537: numpypy __array_interface__
* Fixed issue 1238: Writing to an SSL socket in pypy sometimes failed with a
"bad write retry" message.
* distutils: copy CPython's implementation of customize_compiler, dont call
split on environment variables, honour CFLAGS, CPPFLAGS, LDSHARED and
LDFLAGS.
* During packaging, compile the CFFI tk extension.
The library detection orginally depended on sys.version however that
tends to change a lot and thus a more robust method is used based on
sys.pypy_version_info.
This fixes installation using distutils and corrects output from sysconfig.
Special thanks to Attila Nagy who reported the issue and tracked down
the root issue (allowing me to deliver a quick solution).
Reported by: Attila Nagy <bra@fsn.hu>
Portlint recommends "USE_GCC=yes+" however such an option breaks everything.
Ignore portlint and use "USE+GCC=4.2+" as the port will compile with just about
any valid C compiler.
Changes to port:
* Abstract ${BUILDDIR} for files/Makefile
* Remove MAKE_JOBS_SAFE (depreciated)
* Use "USE_GCC=yes+" as recommended by portlint
Highlights:
* Bugfixes to the ARM JIT backend, so that ARM is now an officially
supported processor architecture
* Stacklet support on ARM
* Interpreter improvements
* Various numpy improvements
* Bugfixes to cffi and ctypes
* Bugfixes to the stacklet support
* Improved logging performance
* Faster sets for objects
- Track the change in build location (s/2.0.2/2.0.x/g)
- Only tested on amd64 as this is only a point releas
- If SANDBOX fails to build, install pypy-2.0.2 and try again
ChangeLog:
* Fix crash in the JIT when calling external C functions in multithreaded context.
Approved by: eadler,bdrewery (mentors, implicit)
A patch that tought _sqlite3.py where to find sqlite3.h and sqlite3.so was
not added with the previous commit.
Approved by: eadler,bdrewery (mentors, implicit)
Port ChangeLog:
* Sqlite3 added as a dependency
* DIST_SUBDIR no longer used as upstream now releases with a proper tarball
* Added ability to translate with pypy running in restricted memory mode
( faster than python2.7 and uses less memory!)
* Added support for pypy modules that use cffi (_sqlite3 and _curses)
Approved by: eadler,bdrewery (mentors, implicit)
The internals of the port have been substantially reworked:
* All predefined instances can be selected via options [1]
* Optionally use options, if user does not overwrite instance list
* Make translation with pypy an option, if it is available.
* Make memory checking more refined [2]
* Add a Wiki page details lang/pypy
* Fix the test target
* Refactor build target (easier to review, edit)
* Rename patches to prevent churn
[1] Although two are broken upstream and one possibly discontinued
[2] My memory limits appear to be too conservative. Set PYPY_IGNORE_MEM for now
Reviewed by: Kuro <poyopoyo@puripuri.plala.or.jp>, rm@
Approved by: bdrewery (mentor)
- Detection of insufficient memory [1]
- Change %% SUB vaes from fixed at python 27 to use any installed version of python [1]
- Fix syntax of non system include "" vs <> [2]
PR: ports/168974 [1]
Submitted by: David Naylor <naylor.b.david@gmail.com> (maintainer) [1]
Reviewed by: scheidel@ (me) [2]
