13:43 tcberner 

Update Qt to 5.6.2 [1,2]

Thanks to the upstream work of Marie Loise Nolden, we could get rid of a handful
of patches, as they have been properly upstreamed. The rest of the work is just
some minor plist changes.

I would like to thank Loise <nolden@kde.org> for the upstream work, and Adriaan
<groot@kde.org> for getting the update into shape.

[1] http://blog.qt.io/blog/2016/10/12/qt-5-6-2-released/
[2] http://wiki.qt.io/Qt_5.6.2_Change_Files

PR: 213530
Exp-run by: antoine
Submitted by: Adriaan de Groot <groot@kde.org>
Reviewed by: rakuco, mat, tcberner
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D8228

 

09:46 rakuco 

Update the Qt5 ports to 5.6.1.

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

 

14:03 rakuco 

qmake5: Set QMAKE_{INC,LIB}DIR_OPENGL.

Follow-up to r404694. When we stopped setting CPATH and LIBRARY_PATH, some
Qt5-based ports (astro/stellarium, audio/musescore, audio/cantata,
irc/quassel, deskutils/owncloudclient) broke because the QtGui headers end
up bringing in GL/gl.h, but -I/usr/local/include was no longer being passed
to the compiler.

This is generally caused by QMAKE_{INC,LIB}DIR_OPENGL being empty, which
leads to some parts of Qt5ConfigExtras.cmake.in being left out when being
processed into Qt5ConfigExtras.cmake. Specifically, the bits of code that
make the directories containing GL/gl.h and libGL.so a dependency of the
Qt5::Gui CMake target were not present.

Fix it by setting those two variables again like we also do in devel/qmake4.

Most ports broken by r404694 are fixed by this change, but not all:
* audio/cantata: Accidentally fixed by this change. Upstream includes the
  TagLib headers wrongly. `taglib-config --cflags' returns
  -I${LOCALBASE}/include/taglib, but the code references headers as
  <taglib/foo.h> instead of <foo.h>.
* multimedia/obs-studio, textproc/sigil, x11/antimicro: Those remain broken,
  linker calls pass -lfoo instead of /path/to/libfoo.so, and they were only
  working because we were passing LIBRARY_PATH to the linker before. They
  need to be fixed separately.

Thanks to antoine@ for the fallout heads-up.

PR:	194088
PR:	195105
PR:	198720
MFH:	2015Q4

 

18:51 rakuco 

Make sure ${WRKSRC}/lib is passed before /usr/local/lib when linking.

This is another shot at fixing the linkage problems that have plagued our
users particularly when upgrading from Qt 5.x to 5.(x+1). Quick recap: in
Qt5, qmake will by default pass QMAKE_LIBDIR to the linker before other
directories such as ${WRKSRC}/lib, which is where the port's libraries are
built. When a user is upgrading Qt, we can end up with the following linker
line:
  c++ -o SomeBinary -lfoo1 -L/usr/local/lib -L${WRKSRC}/lib -lfoo2 -lfoo3
If libfoo2.so is being built by the port and an older version is currently
installed on the system, /usr/local/lib/libfoo2.so will be picked up instead
of the newly-built ${WRKSRC}/lib/libfoo2.so. At best things just work, at
worst SomeBinary needs some new symbol that is not present in the old
libfoo2.so and linking fails. Case in point: bug 198720.

The previous approach, adopted when fixing bug 194088, was to stop setting
QMAKE_{INC,LIB}DIR in the FreeBSD mkspecs and set the CPATH and LIBRARY_PATH
environment variables in Uses/qmake.mk. This way we just did not pass
-L/usr/local/lib to the linker at all and things mostly worked. However,
people using Qt to build their own software without the ports tree were out
of luck, as they would then need need to deal with passing
/usr/local/{include,lib} to the compiler/linker themselves (bug 195105). Not
only that, but if a dependency mentioned /usr/local/lib we would still have
problems anyway (in bug 198720, the GStreamer pkg-config files contain
-L/usr/local/lib, for example).

We now solve the issue by setting the QMAKE_LIBDIR_FLAGS variable in
.qmake.cache to ${WRKSRC}/lib instead. qmake appends the value of
QMAKE_LIBDIR to QMAKE_LIBDIR_FLAGS, so we are always sure -L${WRKSRC}/lib
will come before -L/usr/local/lib in the linker options. Moreover, qmake is
smart enough to automatically call sed(1) and remove references to
${WRKSRC}/lib from .prl and .pc files when installing them.

PR:		194088
PR:		195105
PR:		198720
MFH:		2015Q4

 

09:37 rakuco 

Update Qt5 to 5.4.1.

This is probably the first time our Qt 5 ports are tracking the latest
upstream release :-)

There isn't much to report in this update, thanks to the effort spent in the
5.2->5.3 update: a lot of the work is just small plist and patch updates.
Thankfully, several patches have been upstreamed and are not needed on our
side anymore.

I would like to thank Alex Richardson <arichardson.kde@gmail.com> and Tobias
Berner <tcberner@gmail.com> for their help with the plist updates and
general testing.

PR:		198585

 

09:39 rakuco 

Update Qt5 ports to 5.3.2.

Proudly presented by the KDE on FreeBSD team, with several guest stars.

This update took way longer than initially expected due to us previously
accumulating assumptions and changes to Qt's build system that finally bit
us back with the 5.3 release series, so we had to do a fair amount of
cleanup.

New ports:
- comms/qt5-serialport: Qt functions to access serial ports, originally
                        based on work by Fernando Apesteguia. [1]
- devel/qt5-qdoc: Qt documentation generator, the Qt5 equivalent of
                  devel/qt4-qdoc3. Originally worked on by Tobias Berner.
                  It had already been half-split from devel/qt5-buildtools,
                  we just needed to finish the work.

Dead ports:
- devel/qt5-qmldevtools: Merged into lang/qt5-qml.

Minor changes:
- devel/qt5: Add x11/qt5-x11extras and the new ports to the dependency list.
- graphics/qt5-imageformats: The port now supports the JPEG2000, WEBP,
                             Direct Draw Surface and ICNS formats.
- multimedia/qt5-multimedia: The ALSA and PULSEAUDIO options are now
                             mutually exclusive due to changes introduced in
                             Qt 5.3.0 (the ALSA code is now a proper plugin
                             that is only built if PulseAudio is not used).
- x11/qt5-x11extras: Add USE_LDCONFIG since the port installs a shared
                     library.

The big changes:
- bsd.qt.mk: Set QMAKESPEC instead of QMAKEPATH. [3]
  QMAKEPATH does much more than we want now that we call qmake from the top
  of ${WRKSRC}. qmake uses QMAKEPATH when evaluating the QMAKE_MKSPECS
  property, which is in turn used by qt_config.pri to load the .pri files in
  mkspecs/modules.

  In practice, this means that if people have an older Qt installation those
  files will be used and QT_CONFIG will have values such as "gui" even if
  one is building a port like textproc/qt5-xml, which passes -no-gui to the
  configure script. Consequently, unintended code paths may be enabled or
  the configuration step can just fail if the .pro files expect values that
  are not present in the system-wide, older .pri files.

  We avoid all those problems if we use QMAKESPEC, as qmake does not take
  its value into account when evaluating the QMAKE_MKSPECS property and will
  only parse the files in the mkspec's directory (mkspecs/freebsd-clang, for
  example, instead of all the files in mkspecs).

- Stop explicitly passing ${LOCALBASE} to the compiler. [3]
  qmake's behavior has changed in Qt 5, and the paths set in QMAKE_INCDIR
  and QMAKE_LIBDIR in the mkspecs are passed before any others, such as the
  ones in the build directory themselves.

  In practice, this means that we end up with linker calls like this:

  c++ -o libfoo.so foo.o bar.o -L/usr/local/lib -L/wrkdir/build/lib
      -lQt5Gui -lQt5Core

  So if one already has Qt installed in the system, the older, already
  present version of the libraries in /usr/local/lib will be used instead of
  the newly-built ones in /wrkdir/build/lib.

  QTBUG-40825 discusses this behavior upstream, but there has been no
  agreement on a solution yet.

  For now, the solution adopted is to make the compiler and the linker aware
  of those paths but only try them last after all others, and this is
  achieved by setting the CPATH and LIBRARY_PATH environment variables when
  qmake is being used.

  In addition to setting them in CONFIGURE_ENV and MAKE_ENV, we also need to
  stop changing QMAKE_INCDIR and QMAKE_LIBDIR as well as filter those paths
  from the pkg-config calls qtbase's configure script makes.

- Call qmake from the root of the ${WRKSRC}.

  In Qt 5.3, Qt's build infrastructure has undergone some changes that make
  our previous approach of calling qmake from the directories we want to
  build stop working. Things would break even more in Qt 5.4, in which
  qtbase's configure script does not accept the -process, -fully-process and
  -dont-process arguments anymore (it always behaves as if -process had been
  used).

  Bite the bullet and start calling qmake from ${WRKSRC}. The largest part of
  this change involves changing lines in Makefiles from
    WRKSRC_SUBDIR=	foo/bar
  to
    BUILD_WRKSRC=		${WRKSRC}/foo/bar
    INSTALL_WRKSRC=		${WRKSRC}/foo/bar
  as well as adding patches to .pro files to avoid entering other
  subdirectories and removing post-configure targets that are not necessary
  anymore.

  Since qmake needs to be called from the top of ${WRKSRC} anyway, we can
  also simplify the configuration process for the qtbase ports a little.
  Looking at r10019 it is not clear why we started calling qmake in the
  pre-configure target in addition to the post-configure one (while also
  skipping it in do-configure), but we can now drop this call since letting
  configure behave as if -process had been passed means it will call qmake
  on its own and overwrite the files generated by the pre-configure call. We
  still need to call qmake in post-configure though, as the configure script
  does not pass -recursive when calling qmake and we need to be able to call
  make from any subdirectory when building.

PR:		194762 [1]
PR:		194566 # exp-run with base GCC and clang
PR:		194088 [3]

 

16:50 makc 

KDE/FreeBSD team is happy to present Qt 5 in ports!

Alberto Villa (avilla@) has done all the hard work to create Qt 5 ports.
Trivial update from 5.2.0-beta1 to 5.2.1 by me.

Special thanks for Adriaan de Groot <groot@kde.org> for his assistance for
Qt-5.2.0 update.

Approved by:	portmgr (bapt) (for Mk/bsd.port.mk)