Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464
(via Mk/bsd.default-versions.mk and lang/gcc) which has moved from
GCC 5.4 to GCC 6.4 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++11-lang,
c++14-lang, c++0x, c11, or gcc-c++11-lib.
PR: 219275
lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using using Mk/bsd.octave.mk which in turn has USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
c++11-lang, c++0x, c11, or gcc-c++11-lib.
PR: 216707
- Add PYTHON_PYOEXTENSION and PYTHON_SUFFIX
- Add PYTHON2 and PYTHON3
- Respect PYTHON_VERSION
- Rename PYOEXTENSION to PYTHON_PYOEXTENSION
This change would help:
- Build databases/postgresql*-plpython with Python 3
(It has PLIST issue since bsd.python.mk to Uses/python.mk transition)
- Simplify Makefile
PR: 205807
Differential Revision: https://reviews.FreeBSD.org/D4758
Exp-run by: antoine
- Clean up the Makefile.
- Follow some upstream recommendations (--with-data-packaging=archive,
--disable-renaming, -DICU_NO_USER_DATA_OVERRIDE).
- Patch makefiles to install static libraries with INSTALL_DATA so they
aren't stripped.
- Patch config/mh-bsd-gcc to sync with config/mh-linux-gcc.
- Fix endianness detection in ICU. The code wanted to use BYTE_ORDER
defined in machine/endian.h, but this isn't visible because ICU is
compiled with _XOPEN_SOURCE. Patch the code to use _BYTE_ORDER instead.
- Compile ICU with C++11 compiler to enable move constructors.
- Patch ICU to fix a problem with atomics in the case of a C++11 compiler
without C++11 header <atomic> (like Clang on FreeBSD 9).
- Bump all ports that depend on it due to library version change.
- Add USES=compiler:c++0x to some ports that pick up -std=c++0x from ICU
pkgconfig files.
- Add USES=compiler:c++11-lib to graphics/libcdr01 because it also needs
a C++11 runtime library now. Add this to all ports that depend on it
so their executables load the right libstdc++.so on FreeBSD 9.
PR: 205120
Exp-run by: antoine
Approved by: portmgr (antoine)
include GH_PROJECT/GH_ACCOUNT/GH_TAGNAME. This prevents the distfile
having the same name despite changing one of these values and causing
a bad checksum.
Differential Revision: https://reviews.freebsd.org/D2103
Reviewed by: mat
With hat: bdrewery
conflict with the old scheme and cause a "reroll" or "invalid checksums". This
also avoids clobbering the FreeBSD distcache.
Use a revision in the DISTNAME for USE_GITHUB in case we need to bump this
again for anything. It's more a hint of how to handle it in the future.
Reported by: mat
Discused with: mat, antoine, swills
With hat: portmgr
Using this new scheme allows only setting the _tag_ or _commit hash_ in
GH_TAGNAME and not having to know the hash for a tag. This scheme will
download a tarball that has a different checksum than before due to a changed
directory name for extraction.
The following MASTER_SITES are provided to retain the old checksum and
directory structure (that require GH_COMMIT):
GH -> GHL
GITHUB -> GITHUB_LEGACY
Differential Revision: https://reviews.freebsd.org/D748
Submitted by: amdmi3
Reviewed by: mat, swills, antoine, bdrewery
With hat: portmgr
