While here, chase some KDE4 ports and functionality, these are scheduled for removal on 2018-12-31. Change the default option/flavor to QT5 where applicable or use alternative toolkits like GTK. Submitted by: tcberner Reviewed by: adridg, jhale, rene, tcberner Approved by: portmgr (implicit, flavor hook) Differential Revision: https://reviews.freebsd.org/D17741
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
* 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
QT_PREFIX was a remnant of a bygone time. Reviewed by: rakuco Approved by: rakuco (mentor) Differential Revision: https://reviews.freebsd.org/D8825
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]
to GCC 4.8.3. Part II, Bump PORTREVISIONs. PR: 192025 Tested by: antoine (-exp runs) Approved by: portmgr (implicit)