USES=cmake now supports two additional list variables:
* CMAKE_ON : List of variables to turn on
* CMAKE_OFF : List of variables to turn off
This can be used as a shortcut to append these to CMAKE_ARGS.
For example ports that previously set
CMAKE_ARGS= -DVAR1:BOOL=TRUE -DVAR2:BOOL=TRUE -DVAR3:BOOL=FALSE
can now set this as
CMAKE_ON= VAR1 VAR2
CMAKE_OFF= VAR3
Reviewed by: adridg, rakuco, mat
Differential Revision: https://reviews.freebsd.org/D13636
Some ports depend on permissive or broken behaviour from the GNU BFD
linker, ld.bfd. Clang and GCC support a -fuse-ld= flag to choose a
specific linker, and as we migrate to installing lld as the base system
/usr/bin/ld we'll want to make use of -fuse-ld=bfd to use bfd for ports
that fail to link, or fail to run when linked with lld.
An upstream libtool change[1] from Feb 2016 supports passing through
-fuse-ld=, but it has not yet made it into a release. Patch an
equivalent change into ltmain.sh via Mk/Uses/libtool.mk.
Original proposal just patched ltmain.sh in devel/libtool. That would
address ports that run libtoolize via autoreconf, including lang/mono
which is one of the ports that fails to link with lld and responsible
for many downstream skipped ports. Patching ltmain.sh via libtool.mk
(tijl's suggestion) handles that case as well as ports that include
their own copy of ltmain.sh.
A later change may patch devel/libtool so that -fuse-ld works if using a
ports-installed libtool to build software outside of the ports tree; the
change in this commit is intended to address building in the ports tree.
[1] http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=f9970d99293faf908fdc153a653fa5781095fb7a
PR: 214864, 224514
Reviewed by: tijl
Approved by: portmgr (antoine)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13589
Currently, only python shebangs (e.g. /bin/python, /usr/local/bin/python,
/usr/bin/env python etc.) are reported by stage Q/A and fixed by
USES=shebangfix. We need to do the same for python[23] as well.
Before the problem was not noticeable since many ports had e.g.
USES=python:2, which added a dependency on python2 metaport, however
that's going to switch to USES=python:2.7, and neither it, nor more
widely used USES=python adds a dependency on metaports, so there's
very high probability that python[23] links are not available.
Approved by: portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D13571
This allows to have more complex renaming schemes. Until now, it could
only add a prefix or a suffix, but this was not working at all for man
pages, because it would give man/man1/pyfoo.1.gz-2.7 or
man/man1/pyfoo-1-2.7.gz. With this change, a man page will be correctly
renamed to man/man1/pyfoo-2.7.1.gz.
Unfix ports that were already handling man pages.
PR: 220214
Submitted by: Fukang Chen (previous patch)
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D13444
- flang is only supported on amd64
- with default OPTIONS on amd64, R doesn't link against libflang
- in the case R is build with FLANG option, flang is already added as a
runtime dependency by USES=fortran:flang
With hat: portmgr
This would have given an error when:
- The port uses DIST_SUBDIR
- That sub-directory does not exist
- The current user does not have permission to write in DISTDIR.
Something like:
$ sudo rmdir /usr/ports/distfiles/gallery2
$ make fetch-urlall-list
mkdir: /usr/ports/distfiles/gallery2: Permission denied
*** Error code 1
PR: 222819
Reported by: sunpoet
Sponsored by: Absolight
Before this, it could have been set to the current flavor of the port
that may not have been related to Python at all.
This of course never came up during development because at that time,
the only flavors were the Python flavors.
Reported by: dbn
Sponsored by: Absolight
The requested version of python can be set via USES=python:version
This change allows to build most ports depending on devel/py-gobject3
with DEFAULT_VERSIONS=python=3.x
In the future, one of py3gobject3 or pygobject3 could be deprecated.
Before, it would only create the default symlink if the Python version
was the default Python version. Change that to if the Python flavor is
the default flavor.
PR: 224242
Sponsored by: Absolight
The issue becomes apparent when trying to build lang/php72-extensions
with sodium checked.
PR: 223811
Submitted by: Daniel Ylitalo <daniel@blodan.se>
Approved by: ale
- Pass MAKEFLAGS down into do-depends properly.
- Remove redundant dependencies, run-depends and lib-depends, from
targets that already depend on earlier targets that depend on
the needed targets.
Reported by: emaste
With hat: portmgr
There's a flaw in FLAVOR selection logic which makes python FLAVOR
default to py27 even with DEFAULT_VERSIONS=python=3.6. Fix this and
generate FLAVOR based on PYTHON_DEFAULT, PYTHON2_DEFAULT, PYTHON3_DEFAULT
(in that order) similar to how it's done in other parts of python.mk.
This does not affect FLAVOR in default setup (py27 remains), but
if python default version is modified, it will now properly affect FLAVOR.
Approved by: portmgr (antoine)
Differential Revision: D13326
has changed, so it still should work as well (or not) as before, but it's
essentially untested and if anyone needs an older version from the GCC 4.x
era, 4.9 is still available.
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
To help with flavored ports, helpers are available. In these, replace <*>
with the flavor name.
*_PKGNAMEPREFIX *_PKGNAMESUFFIX *_PLIST *_DESCR will overwrite the variable.
*_CONFLICTS *_CONFLICTS_BUILD *_CONFLICTS_INSTALL *_PKG_DEPENDS
*_EXTRACT_DEPENDS *_PATCH_DEPENDS *_FETCH_DEPENDS *_BUILD_DEPENDS
*_LIB_DEPENDS *_RUN_DEPENDS *_TEST_DEPENDS will append to the variable.
Reviewed by: portmgr
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12483
