From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: →https://reviews.freebsd.org/D15540
Usage:
USES=eigen:<version>[,<type>]
version: 2 or 3 (required)
type: build (default), run
For example:
USES=eigen:2,build,run
will add a BUILD- and RUN_DEPENDS on math/eigen2, and
USES=eigen:3
will add a BUILD_DEPENDS on math/eigen3.
* Convert the existing ports to use it
- biology/iqtree: remove run time dependency (seemed not to be needed)
- graphics/movit: remove run time dependency (seemed not to be needed)
- science/avogadro: add run time dependeny (installed cmake file requires it to be present)
Reviewed by: rakuco, mat
Differential Revision: https://reviews.freebsd.org/D13702
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
Renaming didn't help to unblock 3.x progress as co-existence with 2.x
was no less complex than simply fixing consumers. This commit also
restores directory-level history accidentally lost via git-svn.
PR: 210505
Pointy hat to: jbeich (should've discussed first)
To avoid confusion, the main port is to track the latest release.
Whether to rename includes/libraries as well making it possible to
install 2.x and 3.x side-by-side remains to be investigated.
PR: 210505 (for tracking)
Inspired by: PkgSrc
PYTHON_REL is defined in bsd.port.pre.mk, so this unlikely to ever have
worked unless defined via make.conf. Note, USES=python only supports
overriding PYTHON_VERSION apart from DEFAULT_VERSIONS=python*.
$ make -V PYTHON_VERSION PYTHON_REL=3500
python2.7
$ PYTHON_REL=3500 make -V PYTHON_REL
2712
$ make -V PYTHON_REL PYTHON_VERSION=python3.5
3502
PR: 204519 (for tracking)
Python module of OpenCV 2.4.9 is not compatible with Python 3.x
- both on cmake infrastructure level and on module itself level,
so just mark it as Python 2.x only and remove all the python3
shims - they are don't make any difference anyway.
We can patch that hardly to make it work, but it's better to just
update to latest version that have python3 support out of the box.
PR: 204519 (for tracking)
Instead of defining a variable that is almost always based on CONFIGURE_ENV,
just use CONFIGURE_ENV directly.
This also matches the behavior of other ports that do not use autotools (so
most ports can just worry about CONFIGURE_ENV). Additionally, the fact that
we do not use ?= means we do not have problems if another file in Uses/
needs to set CONFIGURE_ENV (with CMAKE_ENV, the order of the arguments to
USES would matter).
Ports which set CMAKE_ENV have been adjusted accordingly. In most cases,
CMAKE_ENV was just replaced with CONFIGURE_ENV, the exceptions being:
* databases/sqliteman: CMAKE_ENV line removed; setting QMAKESPEC there has
no effect on the build system.
* devel/freeocl: CMAKE_ENV line removed; FREEOCL_CXX_COMPILER is already
retrieved from the CMAKE_CXX_COMPILER variable in the build
system.
* graphics/openimageio: CMAKE_ENV line removed; setting Qt variables there
has no effect on the build system.
Reviewed by: makc
Differential Revision: https://reviews.freebsd.org/D3403
When EIGEN option is off, CMAKE_ARGS is reset, thus enabling build of
tests and docs (causing some leftovers), and, should it be installed,
linking against libdc1394 even when option DC1394 is off. PORTREVISION
bump is needed to address the latter case.
Meanwhile, re-enable make jobs.
Differential Revision: https://reviews.freebsd.org/D2893
Reviewed by: jhale (maintainer)
Approved by: jhale (maintainer)
MFH: 2015Q2
with ffmpeg on processors that do not support SSE instructions. OFF by
default for package building, ON with autodetect for ports to keep with
POLA. [1][2]
- Bump PORTREVISION on all opencv ports
PR: 199715 [1], 200234 [2]
Submitted by: Randy Westlund <rwestlun@gmail.com> [1], sasamotikomi@gmail.com [2]
This allows the gstreamer plugin to actualy link to the needed opencv libraries.
PR: 196021
Approved by: maintainer timeout (4 months)
Obtained from: debian
- Specify major Qt version number to squash some CMake warnings about Qt5
- Use OPTIONS_RADIO for GUI support - build only allows use of one toolkit
- Make OpenGL support optional (off by default since it only works with
GUI support)
- Allow OpenGL support with GTK2
Reported by: Wolfgang Riegler <wolfgang.riegler@gmx.de> [1]
up old headers if a previous version is installed and are not needed for
the main build
Reported by: Andrzej Tobola <ato@iem.pw.edu.pl>, Kevin Oberman <rkoberman@gmail.com>
- Revert options helpers to if statements since the OFF condition is not
applied when OPTIONS_EXCLUDE is used
- Move most of the OpenCV modules from the graphics/opencv-core port to
graphics/opencv, leaving opencv-core as just the bare minimum required
for building ffmpeg with OpenCV support
- Install examples for python and java bindings
- Add new slave port graphics/opencv-java: Java bindings for OpenCV
- Bump PORTREVISION and make dependency adjustments and fixes for
dependent ports
- Add UPDATING entry
- Update to 2.0.1
- Change master sites to SAVANNAH
- Change maintainer email to @FreeBSD.org
- Remove conflict with non existent Port
- USES pathfix pkgconfig
- Add executable
- Add DOCS Option
- Support STAGEDIR and add OPTIONS_SUB
- Use pathfix instead of simple patches
- Adjust patches
- Change WWW
graphics/OpenEXR
- Update to 2.0.1
- Change master sites to SAVANNAH
- Change maintainer email to @FreeBSD.org
- Use the new format for LIB_DEPENDS
- USES gmake pathfix pkgconfig
- Add DOCS and EXAMPLES Options
- Support STAGEDIR and add OPTIONS_SUB
- Change REINPLACE_CMD
- Add extra patch for EXAMPLES
- Remove obsolete patches
- Bump dependent ports' revisions
Approved by: pawel / wg (mentors)
- Fix build with modern compilers in the contrib module [1]
- Fix build of opencv-core with clang in the ts module [2]
- Fix build with QT option [3]
- Fix build of py-opencv with clang [4]
Reported by: avg [1], Robert Huff <roberthuff@rcn.com> [2]
PR: ports/182443 [3], ports/182837 [4]
Submitted by: O. Hartmann <ohartman@zedat.fu-berlin.de> [3], pawel [4]
While here:
- Convert to options helpers
- Convert to new LIB_DEPENDS syntax
- Fix a few typos and portlint(1) warnings
Reported by: avg
Patched by: wg
