06:43 tcberner 

Update Qt5 to 5.15

This is a major upgrade of the Qt libraries [1], [2].

* People that use upgrading mechanisms with incomplete dependency handling
  (portmaster & Co) should make sure to manually remove the existing Qt
  packages to guarantee a safe upgrade. Keep in mind, that Qt does not like if
  you have an incomplete upgrade.

* This version of Qt drops support for OpenSSL 1.0 -- this means that there
  won't be any binary packages for Qt5 provided by the FreeBSD package builders
  for FreeBSD 11.x anymore -- and the same for *all* the ports depending on
  net/qt5-network [3]. If you cannot upgrade to a more recent FreeBSD
  version (12.x, 13.x), you will need to build Qt5 from ports while switching
  to an SSL implementation from ports.

Big thanks are due for
* kai@ for updating webengine (also mikael@)
* Felix Palmen for providing LibreSSL support patches
* adridg@ and lbartoletti@ for helping me fix the fallout

[1] https://www.qt.io/blog/qt-5.15-released
[2] https://wiki.qt.io/New_Features_in_Qt_5.15
[3] https://www.freshports.org/net/qt5-network

PR:		247010
Exp-run by:	antoine

 

04:13 tcberner 

Qt5 update to 5.13.0

For new features, check: https://wiki.qt.io/New_Features_in_Qt_5.13

Thanks to adridg who helped to fix a lot of packages.

Exp-run by:	antoine
PR:		238782

 

14:49 tcberner 

Update Qt5 to 5.12.0

http://blog.qt.io/blog/2018/12/06/qt-5-12-lts-released/

- This breaks support for libressl again. Patches are welcome.

PR:		233705
Exp-run by:	antoine

 

21:30 rakuco 

Update Qt5 ports to 5.9.3.

This took quite a lot of time because Qt's own build system underwent
several changes in 5.8.0 that took a while to adapt to.

And, of course, qt5-webengine is a behemoth that we need to patch like crazy
due to its bundling of Chromium. In fact, most of the Chromium patches in
qt5-webengine have been imported with no changes from www/chromium@433510
("www/chromium: update to 56.0.2924.87").

New port: accessibility/qt5-speech

Bigger changes to Qt5 ports we had to make:
- Qt now allows using a configure.json file to define configuration options
  and specify configuration checks that can be done when qmake is invoked.
  However, configure.json checks done in a subdirectory only propagates to
  subdirectories, and checks elsewhere will fail if all .pro files are being
  parsed at once (i.e. qmake -recursive), so several ports had to switch to
  USES=qmake:norecursive along with manual additional qmake invocations in
  subdirectories in order to work. It's been mentioned in a few places such
  as Qt's bug tracker that qmake's recursive mode is pretty much deprecated,
  so we might switch to non-recursive mode by default in the future.

- Uses/qmake.mk: Introduce QMAKE_CONFIGURE_ARGS. qmake now accepts
  arbitrary options such as '-foo' and '-no-bar' at the end of the
  command-line. They can be specified in QMAKE_CONFIGURE_ARGS.

- graphics/qt5-wayland: The port can only be built if graphics/mesa-libs is
  built with the WAYLAND option, so a corresponding option (off by default)
  was added to the port.

- misc/qt5-doc: Switch to a pre-built documentation tarball. The existing
  port was not working with Qt 5.9. Instead of trying to fix it, switch to
  what Gentoo does and fetch a tarball that already contains all
  documentation so that we do not have to build anything at all. The
  tarball's name and location in download.qt.io look a bit weird, but it
  seems to work fine.

- www/qt5-webengine: Use binutils from ports, Chromium's GN build system
  generates a build.ninja that uses ar(1) with the @file syntax that is not
  supported by BSD ar, so we need to use GNU ar from binutils.

- x11-toolkits/qt5-declarative-render2d: This port was merged into the main
  Qt Declarative repository upstream, and into x11-toolkits/qt5-quick in the
  ports tree.

Changes to other ports we had to make:
- biology/ugene: Drop a '#define point "."' that is not present in more
  recent versions of the port. Defining a macro with such a common name
  causes build issues with Qt 5.9, which uses |point| as an argument name in
  methods.

- cad/qelectrotech: Fix plist with Qt 5.9. Directories are no longer
  installed with `cp -f -R', but rather `qmake install qinstall', which does
  not install

   
%%DATADIR%%/elements/10_electric/20_manufacturers_articles/bosch_rexroth/.directory

  That's a local file that should not even have been part of the tarball
  anyway.

- chinese/gcin-qt5: Add additional private Qt directories (which should not
  be used in the first place) to get the port to build with Qt 5.9.

- devel/qtcreator: Fix plist with Qt 5.9. Something changed in qdoc and some
  test classes no longer generate documentation files.

- security/keepassx-devel: Import a patch sent upstream almost a year ago to
  fix the build with Qt 5.9.

Thanks to antoine for the exp-run, and tcberner and Laurent Cimon
<laurent@nuxi.ca> for landing changes in our qt-5.9 branch.

PR:		224849

 

19:48 tcberner 

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

* 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

 

20:28 tcberner 

Reintegrate textproc/clucene-qt5 into devel/qt5-help

As devel/qt5-help is the only consumer of textproc/clucene-qt5 and the latter
it is part of the same distfile we can simplify it, and get rid of clucene-qt5.

This was spotted by Marie Loise Nolden <nolden@kde.org> -- thanks :)

Reviewed by:	rakuco
Approved by:	rakuco (mentor)
Sponsored by:	https://reviews.freebsd.org/D8638

 

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]

 

21:35 rakuco 

Remove @dirrm and @dirrmtry entries from the Qt ports.

 

11:09 tijl 

Remove libtool .la files from all Qt ports

Approvedy by:	kde (makc)

 

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)