K 10
svn:author
V 6
rakuco
K 8
svn:date
V 27
2015-09-16T08:55:04.571854Z
K 7
svn:log
V 1925
Update the Qt4 ports to 4.8.7.

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]

END