mirror of
https://git.freebsd.org/ports.git
synced 2025-06-03 20:06:29 -04:00
3346021972
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
32 lines
1.4 KiB
Text
32 lines
1.4 KiB
Text
# This file is installed alongside the qmake symlink in
|
|
# ${BUILD_WRKSRC}/qtbase/bin. The qmake binary reads it and overrides some of
|
|
# qmake's built-in properties.
|
|
#
|
|
# qmake's variant properties are not officially documented, so here is
|
|
# a quick explanation:
|
|
# - $$[FOO] refers to the final locations where things are installed. It can be
|
|
# changed in the Paths section of this file.
|
|
# - $$[FOO]/get refers to locations within a build directory, before the files
|
|
# are installed into their final location. It can be changed in the
|
|
# EffectivePaths section.
|
|
# - $$[FOO]/src refers to the source locations of some items (e.g. during a
|
|
# build, some files are expected to be in the source directory, not the build
|
|
# directory). It can be configured via the EffectiveSourcePaths entry.
|
|
#
|
|
# In short, we are tricking qmake into behaving as if we had run `configure
|
|
# -developer-build`: all the QT_* and QT_*/get properties point to
|
|
# ${BUILD_WRKSRC}/qtbase and its subdirectories so that this is treated like a
|
|
# developer build (where the installation prefix is the same as the build
|
|
# directory).
|
|
#
|
|
# Additionally, we point QT_INSTALL_DOC/src to the location where the .qdocconf
|
|
# files are installed by the devel/qt5-qdoc-data port.
|
|
|
|
[EffectivePaths]
|
|
Prefix=%%BUILD_WRKSRC%%/qtbase
|
|
|
|
[EffectiveSourcePaths]
|
|
Documentation=%%QT_DOCDIR%%
|
|
|
|
[Paths]
|
|
Prefix=%%BUILD_WRKSRC%%/qtbase
|