New default version for librsvg2.
Current versions of graphics/librsvg2 are using parts written in rust.
For architectures that do not have support for rust, and for people
who prefer not to have, or are not able to compile rust software due
to hardware limitations, the version can be chosen via this new flag.
The default on almost all architectures is rust.
If you prefer no to use rust, add the following to your make.conf:
DEFAULT_VERSIONS+=librsvg2=legacy
This makes the change committed in r554733 a bit more flexible for people
who are opposed to oxidation.
PR: 251014
Exp-run by: antoine
jurisdiction. Patents are not necessarily related to the license and so
should not be connected to the license framework.
As a project we will officially remove all patent limitations within the
ports tree and leave it to the user or consumer to deal with their local
legislation to determine if they can use the software without legal
restrictions.
Approved by: core
Allow ports to only depend on a component of PyQt for testing.
USES=pyqt:5
USE_PYQT=webengine_test
will add a TEST_DEPENDS on www/py-qt5-webengine
Approved by: portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D23241
patches even if one fail.
This helps when upgrading ports with a large number of patches, like
www/chromium where having to fix one patch, re-do the patching, fix the
fallout, 800 times, is really painful.
This fixes the first attempt at this which would make ports with
multiple patches patching one file somewhat explode.
Bump the minimum required pkg version to a version that accepts
properly lua scripts
Lua script offers the advantages over shell scripts that they are
running in a capsicum sandbox and they are natively rootdir friendly
Reviewed by: portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D21433
Ports using USES=lua:module or lua:flavors will be flavored. A range of
supported lua versions can be set using XX-YY (or XX-, or -YY, or simply ZZ)
for ports not supporting all lua versions.
USES=lua sets LUA_FLAVOR that needs to be used on all dependencies of
flavored lua ports, in a similar way as PHP or Python flavors.
PR: 245038
Submitted by: andrew tao11 riddles org uk
Reviewed by: mat, kevans, russ haley gmail com
Approved by: mat (portmgr)
Differential Revision: https://reviews.freebsd.org/D16494
in 2019 the norm is for applications to support both v4 and v6 version of the ip
stack. Furthermore, the ipv6 category was clearly not consistently spread over
the ports tree defeating the goal of the category.
This is useful when 2 tools do provide the same feature, but the configure
scripts do test for some variables which are not in one of the tool.
For example m4 in base is mostly compatible with GNU m4 when called with the -g
arguement. This wrapper allows to use it with build systems that do check for it
calling --version and expecting GNU in the arguments.
Reviewed by: mat (final discussions on irc)
Differential Revision: https://reviews.freebsd.org/D21835
- This XFCE release uses almost exclusively gtk3, so the USES=xfce
now defaults to gtk3
- Make x11-themes/gtk-xfce-engine an optional dependency(disabled
by default), it only supports gtk2, so would leave miost of this
XFCE version unthemed.
- Add Greybird as an optional and enabled dependency as a modern
theme supporting both GTK versions and all other XFCE parts
- The xfce4-vala port is deprecated and removed. The VALA bindings
are available in the library ports using the GIR and VAPI options
(on by default)
- Fixed various missing library and portlint warnings (portmgr fixit
blanket)
- Default Display Manager changed to lightdm (Thanks to woodsb02
for help)
- Add x11/xfce4-screensaver as an optional dependency to the
xfce4-goodies (enabled by default)
- Remove dependency on x11-fm/thunar-vfs and deprecate the port.
It is EOL upstream and the functionality is included in thunar
itself
Update:
- Added back sysutils/xfce4-places-plugin, updated to 1.8.1
- archivers/thunar-archive-plugin to 0.4.0
- audio/thunar-media-tags-plugin to 0.3.0
- audio/xfce4-mpc-plugin to 0.5.2
- audio/xfce4-pulseaudio-plugin to 0.4.2
- deskutils/xfce4-tumbler to 0.2.7
- devel/thunar-vcs-plugin to 0.2.0 [1]
- devel/xfce4-dev-tools to 4.14.0
- misc/xfce4-appfinder to 4.14.0
- misc/xfce4-weather-plugin to 0.10.0
- multimedia/xfce4-parole to 1.0.4
- sysutils/gigolo to 0.5.0
- sysutils/xfce4-battery-plugin to 1.1.3
- sysutils/xfce4-fsguard-plugin to 1.1.1
- sysutils/xfce4-netload-plugin to 1.3.2
- sysutils/xfce4-power-manage to 1.6.5
- sysutils/xfce4-settings 4.14.1
- sysutils/xfce4-systemload-plugin to 1.2.3
- sysutils/xfce4-wavelan-plugin to 0.6.1
- www/xfce4-smartbookmark-plugin to 0.5.1
- x11-clocks/xfce4-datetime-plugin to 0.8.0
- Added new xfce4-stopwatch-plugin, version 0.3.1
- x11-clocks/xfce4-timer-out-plugin to 1.0.3
- x11-fm/thunar to 1.8.9
- x11-wm/xfce4-desktop to 4.14.1
- x11-wm/xfce4-panel to 4.14.0
- x11-wm/xfce4-session to 4.14.0
- x11-wm/xfce4-wm to 4.14.0
- x11/libexo to 0.12.8
- x11/libxfce4menu to 4.14.1
- x11/libxfce4util to 4.14.0
- x11/xfce4-conf to 4.14.1
- x11/xfce4-dashboard to 0.7.5
- x11/xfce4-screensaver to 0.1.8
- x11/xfce4-screenshooter-plugin to 1.9.6
- x11/xfce4-verve-plugin to 2.0.0
Thanks to: Olivier Duchateau <duchateau.olivier@gmail.com>
PR: 240236
Exp-run by: antoine
Tested by: sbruno
Approved by: sergey.dyatko@gmail.com (maintainer timeout via
email), portmgr (fixit blanket, port breaks with
new Thunar if not updated) [1]
Differential Revision: https://reviews.freebsd.org/D21278
Ports that build out of source now simply can use "USES=cmake"
instead of "USES=cmake:outsource". Ports that fail to build
out of source now need to specify "USES=cmake:insource".
I tried to only set insource where explictely needed.
PR: 232038
Exp-run by: antoine
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
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
Ports using USES=php:phpize, php:ext, php:zend, and php:pecl are now
flavored. They will automatically get flavors (php56, php70, php71, php72)
depending of the versions they support (set with IGNORE_WITH_PHP). As a
consequence, ports using USES=pear and USES=horde are also flavored.
PR: 226242
Submitted by: mat
Exp-run by: antoine
Approved by: portmgr
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D14208
This took quite a lot of time because Qt's own build system underwent
several changes in 5.8.0 that took a while to adapt to.
And, of course, qt5-webengine is a behemoth that we need to patch like crazy
due to its bundling of Chromium. In fact, most of the Chromium patches in
qt5-webengine have been imported with no changes from www/chromium@433510
("www/chromium: update to 56.0.2924.87").
New port: accessibility/qt5-speech
Bigger changes to Qt5 ports we had to make:
- Qt now allows using a configure.json file to define configuration options
and specify configuration checks that can be done when qmake is invoked.
However, configure.json checks done in a subdirectory only propagates to
subdirectories, and checks elsewhere will fail if all .pro files are being
parsed at once (i.e. qmake -recursive), so several ports had to switch to
USES=qmake:norecursive along with manual additional qmake invocations in
subdirectories in order to work. It's been mentioned in a few places such
as Qt's bug tracker that qmake's recursive mode is pretty much deprecated,
so we might switch to non-recursive mode by default in the future.
- Uses/qmake.mk: Introduce QMAKE_CONFIGURE_ARGS. qmake now accepts
arbitrary options such as '-foo' and '-no-bar' at the end of the
command-line. They can be specified in QMAKE_CONFIGURE_ARGS.
- graphics/qt5-wayland: The port can only be built if graphics/mesa-libs is
built with the WAYLAND option, so a corresponding option (off by default)
was added to the port.
- misc/qt5-doc: Switch to a pre-built documentation tarball. The existing
port was not working with Qt 5.9. Instead of trying to fix it, switch to
what Gentoo does and fetch a tarball that already contains all
documentation so that we do not have to build anything at all. The
tarball's name and location in download.qt.io look a bit weird, but it
seems to work fine.
- www/qt5-webengine: Use binutils from ports, Chromium's GN build system
generates a build.ninja that uses ar(1) with the @file syntax that is not
supported by BSD ar, so we need to use GNU ar from binutils.
- x11-toolkits/qt5-declarative-render2d: This port was merged into the main
Qt Declarative repository upstream, and into x11-toolkits/qt5-quick in the
ports tree.
Changes to other ports we had to make:
- biology/ugene: Drop a '#define point "."' that is not present in more
recent versions of the port. Defining a macro with such a common name
causes build issues with Qt 5.9, which uses |point| as an argument name in
methods.
- cad/qelectrotech: Fix plist with Qt 5.9. Directories are no longer
installed with `cp -f -R', but rather `qmake install qinstall', which does
not install
%%DATADIR%%/elements/10_electric/20_manufacturers_articles/bosch_rexroth/.directory
That's a local file that should not even have been part of the tarball
anyway.
- chinese/gcin-qt5: Add additional private Qt directories (which should not
be used in the first place) to get the port to build with Qt 5.9.
- devel/qtcreator: Fix plist with Qt 5.9. Something changed in qdoc and some
test classes no longer generate documentation files.
- security/keepassx-devel: Import a patch sent upstream almost a year ago to
fix the build with Qt 5.9.
Thanks to antoine for the exp-run, and tcberner and Laurent Cimon
<laurent@nuxi.ca> for landing changes in our qt-5.9 branch.
PR: 224849
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
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
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
- Enable FLAVORS.
- Make make describe flavors aware.
- Add a qa check for unique package names amongst flavors.
- Make MOVEDlint understand flavors.
- Add a bit of sanity check to make sure FLAVORS stay lowercase.
- Various fixes.
Reviewed by: portmgr
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12577
old FreeBSD make (pmake) and there are no more users of it left in
the ports tree.
Differential Revision: https://reviews.freebsd.org/D12634
Approved by: portmgr (bapt)
When defined it will create symlinks of some given binaries in a directory which
will be prepended to the PATH.
The syntax is the following:
BINARY_ALIAS= target1=source1 target2=source2
For example to have a "swig" binary in the path which will be pointing at
swig3.0 and a "sed" pointing at GNU sed: gsed
BINARY_ALIAS= swig=swig3.0 sed=gsed
Reviewed by: swills, adamw, mat
Approved by: swills (portmgr)
Differential Revision: https://reviews.freebsd.org/D12603
Using ninja instead of make (1) can lead to significant speed ups while building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
This uses will handling building software that uses the meson
build system. Expand the option framework to handle MESON options.
Approved by: portmgr (swills@)
Differential Revision: https://reviews.freebsd.org/D104091
