Arch and Debian) that implements the atomics; removes the use of generic
atomics on aarch64. This allows textproc/qt4-dbus to build.
PR: 223988
Reported by: linimon
Approved by: tcberner (mentor)
Obtained from: Fedora (url is in patch)
Differential Revision: https://reviews.freebsd.org/D13935
variables deprecation revision
WITHOUT_NLS 2013-12-13 r336337
WITH_/WITHOUT_ 2014-02-24 r345870
NOPORT(DOC|EXAMPLE)S 2014-04-19 r351587
WITH_BDB_VER 2016-05-02 r414444
OVERRIDE_LINUX_BASE_PORT 2016-09-05 r421387
WITH_OPENSSL_(BASE|PORT) 2016-06-16 r416965
While there, add an ERROR variable that works like DEV_ERROR, but for
user facing errors, and move NOPORTDOCS,
NOPORTEXAMPLES and WITHOUT_NLS to it.
Cleanup bsd.sanity.mk a bit.
Fix fallout.
PR: 224613
Submitted by: mat
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D13490
The helpers were being evaluated before the default FLAVOR was set. The
helpers worked fine if the FLAVOR was specified by the user but not if
it was left to the default value. Resolve this by moving the helpers
right after the default FLAVOR is set.
PR: 224879
exp-run by: antoine
Approved by: portmgr (implicit)
MFH: 2018Q1
Differential Revision: https://reviews.freebsd.org/D13756
With the update to Qt 5.9.3, the configure script and qmake expect an mkspec
name, not an absolute path, which is why r458293 switched to using
${QMAKESPEC:T}.
However, the :T modifier breaks things when CXX is set to an absolute path
instead of just "c++", QMAKE_COMPILER is a shell string that will be evaluated
only after make invokes `configure' with CONFIGURE_ARGS. In other words, we end
up turning something like
$$(ccver="$$(/usr/bin/c++ --version)"; case "$$ccver" in *clang*) echo clang ;; *) echo g++ ;; esac)
into
/c++ --version)"; case "$$ccver" in *clang*) echo clang ;; *) echo g++ ;; esac)
which is obviously invalid.
We now just avoid being too smart and set a separate variable called
QMAKESPECNAME, which contains only the mkspec name and that we use both when
setting CONFIGURE_ARGS as well as to create QMAKESPEC.
PR: 224971
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
This otherwise prevents properly setting FLAVOR to the default internally
since it is in a separate namespace in bmake that is read-only.
Approved by: portmgr (implicit)
MFH: 2018Q1
The code I removed was wrong but it still achieved the proper effect of
removing FLAVOR from .MAKEOVERRIDES. This is still needed and now is
done properly without truncating away all of the other valuable variables.
Pointyhat to: bdrewery
Approved by: portmgr (implicit)
MFH: 2018Q1
There is no such variable as ${MAKEOVERRIDES}, only ${.MAKEOVERRIDES}, so this
code was simply truncating .MAKEOVERRIDES entirely which could cause performance
and other odd issues with OSREL and make recursion.
We don't want to leak FLAVOR to child sub-makes but that can be fixed later;
this code was not doing what it intended.
Approved by: portmgr (implicit)
MFH: 2018Q1
Originally written by jrm in https://reviews.freebsd.org/D12964, but it makes
sense to decouple this stylistic change from what is being worked on in that
patch.
- Remove the use of comp_DETECT.
- Remove all comp_DETECT variables.
- Remove a use of comp_DETECT outside of gnome.mk
- Remove py3gobject3.
- Have ports depending directly on devel/py-gobject3 use gnome to do it.
PR: 224618
Submitted by: mat
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D13550
Upstream no longer ships the contents of misc/py-qt5-doc, so the port has been
removed.
This is also a requirement for updating the Qt5 ports, as the PyQt5 version
currently in the tree has license conflicts with later Qt versions.
Big thanks to tcberner for doing most of the work here, and antoine for the
exp-run.
PR: 224739
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
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
