ports/databases/qt4-sqlite-plugin, branch 2017Q2

Update Qt5 to 5.7.1, and unify the Qt4 and Qt5 ports some more

2017-02-18T19:48:05Z

* 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 . 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

Unmark broken on powerpc64

2016-09-15T01:41:28Z

These ports built successfully

many ports: mark broken on powerpc64

2016-04-21T16:43:14Z

Switch to USES=sqlite:2.

2016-03-11T10:45:42Z

No functional changes.

qt4 sqldrivers: Switch to a proper qmake build, use Makefile.sqldrivers.

2016-03-10T14:11:16Z

We've recently started receiving pkg-fallout emails because qt4-mysql-plugin is failing to build in HEAD. It turns out we were using some custom-made Makefile.bsd files to drive the builds, and they did not always register all dependencies between the files correctly. Fix it by switching to a proper qmake build that uses the .pro files shipped with Qt4 itself: they can be used without running the `configure' script almost as if they were not part of the Qt distribution itself. By doing this we can stop having our own Makefiles and also stop setting a lot of variables in the port Makefiles. While here, consolidate most of the variable setting into a single Makefile.sqldrivers in devel/qt4 (like we already do for devel/qt5) so that each of the qt4-*-plugin ports only need to set a few values such as the plugin name and additional USES or includes that might be necessary. Bump PORTREVISION because we now include the debug versions of the plugins in PLIST_FILES when the ports are built with WITH_DEBUG=yes (they were already shipped before, but not registered in the plists).

Update the Qt4 ports to 4.8.7.

2015-09-16T08:55:04Z

According to upstream, this is the last planned Qt4 release. A list of changes since 4.8.6 can be found here: 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 (). 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 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]

Cleanup plist

2014-10-20T10:41:12Z

databases/sqlite2:

2014-09-11T21:54:45Z

- Convert to USES=libtool and bump dependent ports

Unbreak Qt4 ports that do not extract src/corelib after r362770.

2014-07-24T17:35:09Z

The easiest solution is to just make them extract it (it's not a big directory anyway). This can be reverted once 4.8.7 is released.

In preparation for Qt 5 ports:

2014-01-06T16:16:52Z

Mk/Uses/qmake.mk: - Add support for out-of-source builds - Add support for Qt 5 ports - Respect WITH_DEBUG Mk/bsd.qt.mk: - Massive rework for Qt 5 ports - Remove '-phonon' from global configure args, thus allow qt4-designer and qt4-qtconfig to be built without Phonon support [1] devel/qmake4: - Improve mkspecs for gcc (mainly sync with linux version) and clang devel/qt4-corelib: - Convert to USES=iconv - Remove ancient patch devel/qt4-designer: - Remove reference to WRKSRC from installed pkgconfig files [2] - Don't build Qt Designer plugin for Phonon from outdated Qt sources. Separate port for plugin will be committed later devel/qt4-assistant-adp, devel/qt4-libqtassistantclient: - Convert to USES=qmake Clean up Qt4 ports: - Update comments - Update description; use common description - Consistently use QT_INCDIR, QT_LIBDIR, etc. - Use options helpers - Convert to new LIB_DEPENDS syntax - Update DESKTOP_ENTRIES to avoid conflicts with Qt 5 ports - Rename/move several ports for unification with Qt 5 ports PR: ports/184620 [1] Reported by: Kevin Zheng PR: ports/181141 [2] Reported by: thierry PR: ports/185101 Exp-run by: bdrewery This is mostly solely avilla's work in area51, kudos to him! And a couple commits from myself, so you know who's collecting pointyhats :)