13:21 rakuco 

Use the right macro name when checking whether libc++ is being used.

This fixes a copy-paste error introduced in r397043 ("Update the Qt4 ports to
4.8.7"): libc++ defines _LIBCPP_VERSION, not _LIBCPP_VER (which is defined by a
Dinkumware-based standard library used by QNX). In practice, this meant
Q_COMPILER_INITIALIZER_LISTS was never being enabled with clang.

Submitted by:	Tobias Berner <tcberner@gmail.com>

 

18:08 rakuco 

Make devel/qt4's clang+base libstdc++ patch work without changes to
x11/kdelibs4.

Unconditionally including ciso646 in qglobal.h to check for libc++ makes
including qglobal.h from C programs fail.

qglobal.h is not supposed to be used in C programs, but kdelibs4's
FindQt.cmake ends up calling CHECK_SYMBOL_EXISTS() instead of
CHECK_CXX_SYMBOL_EXISTS() to check if some macros are defined. Since
kdelibs4 is in maintenance mode, our changes to it can be avoided if we just
check for __cplusplus before including ciso646 (<initializer_list> is not
available in C anyway).

 

08:55 rakuco 

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]

 

22:24 rakuco 

Update the patch introduced in r362770.

Change a preprocessor line with no directive to a normal line with a
comment. While most preprocessors work fine with a line like

  # /* no directive in this line */

devel/smokegen's fails, and breaks devel/smokeqt.

PR:		192095

 

08:37 rakuco 

Backport my patch to make Qt correctly detect clang's support for C++11
features.

So far, Qt4 was basing its check for compiler support for C++11 features
(auto types, lambdas, rvalue references and others) on the values of
__GNUC__ and __GNUC_MINOR__. This works for GCC, but not for clang, whose
__GNUC_MINOR__ is stuck at 2. In practice, this meant Qt programs built
using clang were never able to use C++11 features which are conditionally
available in classes such as QList. This patch makes the detection more in
line with what Qt5 does (checks for GCC and clang are in separate sections
and are done differently).

I couldn't find cases of this negatively affecting any port so far, but it
is useful to have -- Akonadi's unit tests require C++11 support in Qt, for
example.

Only qt4-corelibs's PORTREVISION was bumped to make the new qglobal.h be
installed. Checks for these C++11 features are only present in headers of
other Qt4 ports, so there's no need to rebuild them.