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
* 222612: www/qt5-webkit: for armv6/v7: The cacheFlush support is missing on this platform
* 216816: devel/qt5: In arch.test, use CXXFLAGS from make environment
PR: 222612,216816, 223289
Exp-run by: antoine
Submitted by: mmel, mikael.urankar@gmail.com
Reported by: Mark Millard <markmi@dsl-only.net>, mmel
Reviewed by: mmel, mikael.urankar@gmail.com
Differential Revision: https://reviews.freebsd.org/D12816
Qt has been looking for its dependencies in PREFIX, rather than in
LOCALBASE. Dependencies are expected to exist in LOCALBASE, but
PREFIX may be set arbitrarily by the end-user. When PREFIX != LOCALBASE,
Qt-based ports failed to build.
PR: 222994
Reported by: kargl
Approved by: tcberner (kde)
Exp-run by: antoine
MFH: 2017Q4
Differential Revision: https://reviews.freebsd.org/D12666
Qt WebEngine provides functionality for rendering regions of dynamic web
content. In other words, this is Chromium's Blink web engine and parts of
Chromium's content layer wrapped by Qt. Qt WebKit is deprecated upstream, and
WebEngine is the future.
This port has been in the works for a very long time, with contributions by
myself, tcberner, Adriaan de Groot and Marie Loise Nolden.
Since most of the port is just a large part of Chromium's code base, this means
sharing some of the pain www/chromium goes through by having to patch a ton of
files. We cannot share the exact same patches because this version of Qt
WebEngine is based on an older Chromium release.
I have verified that the port works, but it is possible that many things are
still wrong or missing, so bug reports are encouraged.
Reviewed by: Adriaan de Groot <groot@kde.org>, tcberner
Differential Revision: https://reviews.freebsd.org/D12063
Since r422306, we use a separate distinfo file for www/qt5-webkit because it is
no longer part of official Qt5 releases. However, we forgot to remove it from
QT_DIST in bsd.qt.mk, which means `make makesum' from other Qt5 ports was
trying to fetch qt5-webkit from the wrong location.
Reviewed by: tcberner
Marketing blurb [1]:
QtWayland is a Qt 5 module that wraps the functionality of Wayland.
QtWayland is separated into a client and server side. The client side
is the wayland platform plugin, and provides a way to run Qt applications
as Wayland clients. The server side is the QtCompositor API, and allows
users to write their own Wayland compositors.
This is mostly needed at the moment to make upstream KDE-CI happy, therefore
we don't wire it into the metaport devel/qt5.
It requires a little change to devel/qt5-qmake, as we needed to modify the
installed bsd.conf to know about wayland/egl.
Created together with Adriaan de Groot <groot@kde.org>.
Reviewed by: rakuco, groot_kde.org
Differential Revision: https://reviews.freebsd.org/D11744
libdeclarative_qmlwebsockets.so is not installed into ${QT_LIBDIR}, which
causes the dependency logic in bsd.qt.mk to actually do something equivalent to
this instead:
BUILD_DEPENDS+= ${QT_LIBDIR}/${QT_QMLDIR}/QtWebSockets/libdeclarative_qmlwebsockets.so:www/qt5-websockets-qml
RUN_DEPENDS+= ${QT_LIBDIR}/${QT_QMLDIR}/QtWebSockets/libdeclarative_qmlwebsockets.so:www/qt5-websockets-qml
which translates into something like
/usr/local/lib/qt5//usr/local/lib/qt5/qml/QtWebSockets/libdeclarative_qmlwebsockets.so:www/qt5-websockets-qml
which obviously does not exist.
Instead of settin websockets-qml_LIB, set websockets-qml_PATH like we do for
other QML ports, so that our dependency logic does not needlessly prepend
${QT_LIBDIR} there. This fixes devel/qt5's build.
PR: 220045
This splits qt5-websockets into a qt5-websockets port containing the core parts,
and a qt5-websockets-qml port with the QML parts. The QML parts depend on Qt Quick,
so on the GUI parts (and hence X11) while the core parts do not.
PR: 220045
Submitted by: Adriaan de Groot <groot@kde.org>
* qtdiag outputs diagnostics on the current Qt installation and can be helpful to find issues.
* qtpluginfo is useful while writing plugins for Qt5/KDE Plasma
Reviewed by: rakuco, mat
Differential Revision: https://reviews.freebsd.org/D11280
gold linker from binutils 2.28 may produce duplicate library
symbols, which makes shared libraries created with it not usable
with conventional ld linker.
PR: 218187
Submitted by: amdmi3
* Update Qt5 to 5.7.1
* Move Qt4 binaries to lib/qt4/bin
* Move Qt5 libraries to lib/qt5/lib
By moving the libraries we should finally be able to get rid of the inplace
upgrade bug (see ports bugs 194088, 195105 and 198720): when Qt5's libraries
were lying in /usr/local/lib, which would often get added by pkgconfig to the
linker paths via dependencies, the already installed libraries were linked
against, instead of the ones that were being built. This forced us to make
sure, that -L${WRKSRC}/lib was always coming before -L/usr/local/lib in the
linker flags. With this change this should no longer be the case.
* Rename some ports to match the rest (foo-qtX -> qtX-foo)
* Depend on new port misc/qtchooser [see UPDATING & CHANGES]
There are several new Qt5 ports which all have been created by Marie Loise Nolden
<nolden@kde.org>. Thanks again.
PR: 216797
Exp-Run by: antoine
Reviewed by: rakuco, mat, groot_kde.org
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D9213
As noticed in x11-toolkits/qt5-charts we never corrected the way in which qmake
sets the pkgconfig path for Qt5-modules. Instead there was a sed-call on the
generated Makefiles in bsd.qt.mk in the target qt-pre-install.
This diff modifies devel/qmake5 to set QMAKE_PKGCONFIG_DESTDIR to
../libdata/pkgconfig from the default pkgconfig.
As we split Qt-base into multiple ports, simply patching devel/qmake5 is not
enough, as the other base-ports will use the file from inside the tarball.
Therefore add it as an extrapatch for the Qt-base ports.
As this affects the same file extrapatch-libtool in devel/qt5 touched, rename
this one and add a hunk to do this change too.
Note: qt4 ports are unaffected, as they never were converted to used the
qt-preinstall target, and still contain the sed-call in their Makefiles.
Reviewed by: rakuco
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D8713
As at the moment QT_BINDIR and QT_LIBDIR are 'bin' respectively 'lib' depending
on the Qt version these subs ended up at many wrong places in plists.
So only export it if QT_DIST is set.
PR: 210227
Reviewed by: mat, rakuco
Approved by: portmgr (mat), rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D8378
As devel/qt5-help is the only consumer of textproc/clucene-qt5 and the latter
it is part of the same distfile we can simplify it, and get rid of clucene-qt5.
This was spotted by Marie Loise Nolden <nolden@kde.org> -- thanks :)
Reviewed by: rakuco
Approved by: rakuco (mentor)
Sponsored by: https://reviews.freebsd.org/D8638
The dependency code from kde.mk can add LIB_DEPENDS if the sense-file is a
library. Import this into bsd.qt.mk
PR: 214744
Reviewed by: rakuco, mat
Approved by: mat (mentor), rakuco (mentor)
Exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D8602
Thanks to the upstream work of Marie Loise Nolden, we could get rid of a handful
of patches, as they have been properly upstreamed. The rest of the work is just
some minor plist changes.
I would like to thank Loise <nolden@kde.org> for the upstream work, and Adriaan
<groot@kde.org> for getting the update into shape.
[1] http://blog.qt.io/blog/2016/10/12/qt-5-6-2-released/
[2] http://wiki.qt.io/Qt_5.6.2_Change_Files
PR: 213530
Exp-run by: antoine
Submitted by: Adriaan de Groot <groot@kde.org>
Reviewed by: rakuco, mat, tcberner
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D8228
WRKSRC is not what we want here: when USES=qmake:outsource is used (such as
in www/webkit-qt5), the build actually takes place in ${WRKDIR}/.build, so
we were creating .qmake.cache in the wrong location and passing the wrong
directory to the linker via -L. With CONFIGURE_WRKSRC, we get the right
value regardless of whether :outsource is used or not.
PR: 212859
Reviewed by: tcberner
MFH: 2016Q3
This took longer than expected, but there are quite a few changes to the
existing ports and a few new ones.
General upstream changes:
- Starting with Qt 5.6.2, Qt will fail at configuration time if LibreSSL is
being used. According to the discussion here:
https://codereview.qt-project.org/#/c/154800/
The Qt project is not opposed to LibreSSL, but does not want to mix
support for it into the OpenSSL backend code, especially as they move
towards supporting OpenSSL 1.1.
People interested in LibreSSL support are welcome to submit a separate
backend upstream, but are expected to maintain it. We (kde@) are not
opposed to carrying some patches authored by others in the future, as long
as they are not huge and destabilizing.
- When Qt detects the compiler supports C++11, it will pass -std=gnu++11 by
default (this is an upstream change). You can add "CONFIG -= c++11" to
your .pro. Qt 5.7 will require C++11.
- www/webkit-qt5: The QtWebKit module is deprecated upstream, and is shipped
separately as a community release tarball. kde@ does not have an ETA for a
qt5-webengine port, as it requires a huge effort (and number of patches)
similar to maintaining www/chromium itself.
- x11-toolkits/qt5-declarative has been deprecated upstream. The last
release is 5.5.1.
Relevant changes:
- devel/qmake5: The freebsd-clang mkspec has become the default mkspec on
FreeBSD, replacing the outdated freebsd-g++ one that was moved to
unsupported/ (it still works though).
- devel/qt5-qdoc: qdoc was moved to qttools upstream, but its data files are
still in qtbase. The data files are now in the qt5-qdoc-data port.
- misc/qt5-doc: Clean up and stop requiring a compiler and fumbling with
mkspecs. Instead of running the `configure' script, which requires a
compiler and adjustments to the mkspecs files and also ends up building a
new qmake binary, we now leverage USES=qmake to generate all the Makefiles
from the top-level qt.pro. Getting this to work requires some tricks,
though, and qt.conf.in has a longer explanation of what's being done.
Switch to USES=gmake to be able to drop MAKE_JOBS_UNSAFE=yes.
New ports:
- comms/qt5-serialbus
- devel/qt5-qdoc-data
- x11-toolkits/qt5-quickcontrols2
Big thanks to Adriaan de Groot (groot@kde.org), tcberner@ and Loise Nolden
(nolden@kde.org) for the huge amount of work they put into this
patch. Loise in particular also sent quite a few changes upstream that were
essential for this update to work.
PR: 211916
The patch moves the "doc" port in bsd.qt.mk from _USE_QT4_ONLY to
_USE_QT_ALL and bumps the PORTREVISION in devel/qt5 for the inclusion
of the qt5-doc port into the qt5 metaport.
Pre-Work for updating qtcreator to 4.0 for adding options to install
qt5-doc and qt5-examples to make qtcreator actually usable for
serious qt development.
PR: 209910
Submitted by: Ralf Nolden <nolden@kde.org> (kde)
This is the latest stable release at time of writing.
Release announcement: http://blog.qt.io/blog/2015/07/01/qt-5-5-released/
New features in Qt 5.5: https://wiki.qt.io/New_Features_in_Qt_5.5
As usual, huge thanks to Tobias Berner (tcberner@gmail.com) for all his work
on these ports in kde@'s experimental area51 repository. He's the one who
started the update and did a lot of the initial work on Qt 5.5. Ralf Nolden
(nolden@kde.org) has contributed the initial version of most of our new Qt5
ports.
Also thanks to Yuri Victorovich (yuri@rawbw.com) for contributing PR 205805
with his own patch for the 5.5.1 update. Some of his changes there prompted
additional fixes and changes present in the final patch generated from our
experimental repository.
New ports:
- comms/qt5-connectivity, comms/qt5-sensors, devel/qt5-location,
graphics/qt5-3d, net/qt5-enginio, x11-toolkits/qt5-canvas3d,
x11-toolkits/qt5-uiplugin.
General changes in all Qt5 ports:
- All Qt5 ports are now built with -Wl,--as-needed to avoid overlinking,
which is a problem with qmake-based because the libraries passed to the
linker come from the modules .pri files and many are not necessary.
- With this change, several ports had their USE_QT5 lines adjusted to
explicitly include some libraries that were pulled in implicitly, and to
exclude libraries no longer required with -Wl,--as-needed.
Changes in specific ports:
- devel/qt5: Drop the SQL_PLUGINS and TOOLS options and depend on all Qt5
ports by default. It makes the Makefile much simpler, and those options
were already on by default.
- devel/qt5-core: The clang+base libstdc++ workaround has been expanded and
more C++11 features have been disabled when that combination is used by a
port (basically, FreeBSD 9 with USES=compiler:c++11-lang). The disabled
features have explanations for why they were disabled in the patched
header itself.
- devel/qt5-designer: uiplugins has been split out following a similar
change upstream. By depending on qt5-uiplugin, qt5-uitools avoids having
to depend on the big qt5-designer port.
- multimedia/qt5-multimedia: The port now uses GStreamer 1.0 instead of
0.10.
- net/qt5-network: The port now depends on libproxy for proxy settings.
Using libproxy allows proxy settings to be read from different sources,
and also allows .pac files to work with Qt.
- www/qt5-webkit: The port now uses GStreamer 1.0 instead of 0.10.
PR: 205805
PR: 206435
This is similar to what we did for Qt4 in r362770. Some C++11 features actually
depend on the C++ standard library, such as <initializer_list> or std::move().
So far, ports with USES=compiler:c++0x and similar failed to build with Qt5 on
FreeBSD 9.x, as base libstdc++ is very old and does not support those C++11
features.
Piggyback on a check that is already present upstream for OS X, which has the
same ancient libstdc++ version. Apple's version has a custom patch with version
macros that we can't use, so we make a broader check and disable the features
that depend on a modern standard library if libc++ is not used.
This is another shot at fixing the linkage problems that have plagued our
users particularly when upgrading from Qt 5.x to 5.(x+1). Quick recap: in
Qt5, qmake will by default pass QMAKE_LIBDIR to the linker before other
directories such as ${WRKSRC}/lib, which is where the port's libraries are
built. When a user is upgrading Qt, we can end up with the following linker
line:
c++ -o SomeBinary -lfoo1 -L/usr/local/lib -L${WRKSRC}/lib -lfoo2 -lfoo3
If libfoo2.so is being built by the port and an older version is currently
installed on the system, /usr/local/lib/libfoo2.so will be picked up instead
of the newly-built ${WRKSRC}/lib/libfoo2.so. At best things just work, at
worst SomeBinary needs some new symbol that is not present in the old
libfoo2.so and linking fails. Case in point: bug 198720.
The previous approach, adopted when fixing bug 194088, was to stop setting
QMAKE_{INC,LIB}DIR in the FreeBSD mkspecs and set the CPATH and LIBRARY_PATH
environment variables in Uses/qmake.mk. This way we just did not pass
-L/usr/local/lib to the linker at all and things mostly worked. However,
people using Qt to build their own software without the ports tree were out
of luck, as they would then need need to deal with passing
/usr/local/{include,lib} to the compiler/linker themselves (bug 195105). Not
only that, but if a dependency mentioned /usr/local/lib we would still have
problems anyway (in bug 198720, the GStreamer pkg-config files contain
-L/usr/local/lib, for example).
We now solve the issue by setting the QMAKE_LIBDIR_FLAGS variable in
.qmake.cache to ${WRKSRC}/lib instead. qmake appends the value of
QMAKE_LIBDIR to QMAKE_LIBDIR_FLAGS, so we are always sure -L${WRKSRC}/lib
will come before -L/usr/local/lib in the linker options. Moreover, qmake is
smart enough to automatically call sed(1) and remove references to
${WRKSRC}/lib from .prl and .pc files when installing them.
PR: 194088
PR: 195105
PR: 198720
MFH: 2015Q4
Modify make describe to automatically prepend ${PORTSDIR} if the path for the
port is not absolute
Checked with poudriere, portmaster, portupgrade
PR: 203685
Exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D3866
Qt 5 does the following during the build of qt5-multimedia:
--- qt-post-install ---
echo "# define QT_GSTREAMER" >> /wrkdirs/usr/ports/multimedia/qt5-multimedia/
work/stage/usr/local/include/qt5/QtCore/modules/qconfig-multimedia.h
echo "# define QT_GST_VERSION=1.0" >> /wrkdirs/usr/ports/multimedia/
qt5-multimedia/work/stage/usr/local/include/qt5/QtCore/modules/qconfig-multimedia.h
echo "# define QT_XVIDEO" >> /wrkdirs/usr/ports/multimedia/qt5-multimedia/
work/stage/usr/local/include/qt5/QtCore/modules/qconfig-multimedia.h
That's (second line) not how #define works in C of C++
The resulting qconfig-multimedia.h file contains this:
#if !defined(QT_GST_VERSION=1.0) && !defined(QT_NO_GST_VERSION=1.0)
# define QT_GST_VERSION=1.0
#endif
This patch filters out the "=1.0" from the define. Bump qt5-multimedia
since the installed header needs to be corrected.
Reported by: antoine@
Patch submitted by: Adriaan de Groot <groot@kde.org>
According to upstream, this is the last planned Qt4 release.
A list of changes since 4.8.6 can be found here:
<http://download.qt.io/official_releases/qt/4.8/4.8.7/changes-4.8.7>
Porting notes and changes:
- Remove several patches that have been upstreamed.
- Make Uses/qmake.mk pass the contents of LIBS to the qmake environment. [1]
- Repurpose devel/qt4/files/extrapatch-src-corelib-global-qglobal.h now the
original patch is part of the release (curiously enough, the original
patch was never actually used, as the ?= assignment in r362837 after
r362770 was never possible).
This works around the way compiler support for C++11 features is detected
in Qt 4.8.7: while it originally only uses the compiler to determine if
something is supported or not, the initializer lists feature also depends
on the C++ standard library being used. It's a problem in FreeBSD 9.x,
where USES=compiler:c++0x or USES=compiler:c++11-lang means we will use
clang to build a port but use libstdc++ from base (GCC 4.2). The latter
obviously does not support initializer lists, and the build fails because
Qt tries to include headers that do not exist (<initializer_list>).
Since detecting libstdc++'s version is not trivial (we need to include a
non-lightweight header like cstdio and then check for __GLIBCXX__), we
just enable Q_COMPILER_INITIALIZER_LISTS support only when libc++ is used
(there should be no reason for someone to be using clang with GCC 4.8's
libstdc++, for example).
x11/kdelibs4's FindQt4.cmake had to include a backported change from the
upstream FindQt4.cmake in CMake itself to use a C++ compiler to detect
flags like Q_WS_X11, otherwise the inclusion of <ciso646> in qglobal.h
makes the build fail.
This patch contains changes by me, makc@ and alonso@.
PR: 202552 [1]
PR: 202808 [exp-run]
Submitted by: pawel@ [1]
The QtWebSockets module implements the WebSocket protocol as specified
in RFC 6455. It solely depends on Qt (no external dependencies).
http://doc.qt.io/qt-5/qtwebsockets-index.html
Submitted by: Tobias Berner <tcberner@gmail.com>
Qt-5.4 introduced a new component: Qt WebChannel
The Qt WebChannel module provides a library for seamless integration of C++ and
QML applications with HTML/JavaScript clients. Any QObject can be published to
remote clients, where its public API becomes available.
https://doc-snapshots.qt.io/qt5-5.4/qtwebchannel-index.html
Approved by: makc (mentor)
Submitted by: Tobias Berner <tcberner@gmail.com> via area51 commit
This is probably the first time our Qt 5 ports are tracking the latest
upstream release :-)
There isn't much to report in this update, thanks to the effort spent in the
5.2->5.3 update: a lot of the work is just small plist and patch updates.
Thankfully, several patches have been upstreamed and are not needed on our
side anymore.
I would like to thank Alex Richardson <arichardson.kde@gmail.com> and Tobias
Berner <tcberner@gmail.com> for their help with the plist updates and
general testing.
PR: 198585
split from from devel/qt4-linguist (similar to Qt 5 ports). These console
tools are often used for localization support in Qt ports, having them
standalone is quite useful. This work is based on Tobias Berner patch [1].
PR: 190929 [1]
Requested by: amdmi3, koobs
This is a command-line interface to QStandardPaths, part of qttools. It is
used by the KDE Frameworks 5 ports, which will be added in the future.
While here, also add x11-toolkits/qt5-quickcontrols to devel/qt5 which I had
forgotten to do before.
Submitted by: Tobias Berner <tcberner@gmail.com>
