Qt4 deprecation: Remove Qt4 and its consumes.

2019-03-15 accessibility/qt4-accessible: Qt4 has been EOL since december 2015
2019-03-15 astro/qlandkartegt: Qt4 has been EOL since december 2015
2019-03-15 astro/stellarium-qt4: Qt4 has been EOL since december 2015
2019-03-15 astro/xglobe: Qt4 has been EOL since december 2015
2019-03-15 audio/acoustid-fingerprinter: Qt4 has been EOL since december 2015
2019-03-15 audio/cueplayer: Qt4 has been EOL since december 2015
2019-03-15 audio/esperanza: Qt4 has been EOL since december 2015
2019-03-15 audio/lastfm-desktop: Qt4 has been EOL since december 2015
2019-03-15 audio/minitunes: Qt4 has been EOL since december 2015
2019-03-15 audio/mixxx20: Qt4 has been EOL since december 2015
2019-03-15 audio/mumble: Qt4 has been EOL since december 2015
2019-03-15 audio/murmur: Qt4 has been EOL since december 2015
2019-03-15 audio/puddletag: Qt4 has been EOL since december 2015

multimedia/gstreamer-qt4: remove dependency on automoc4 after r488807

MFH:		2019Q1

devel/boost-*: update to 1.69.0

Changes:	http://www.boost.org/users/history/version_1_69_0.html
PR:		232525
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D17645

Mark QT4 ports/functionality for removal on 2019-03-15

While here, chase some KDE4 ports and functionality, these are scheduled for
removal on 2018-12-31. Change the default option/flavor to QT5 where applicable
or use alternative toolkits like GTK.

Submitted by:	tcberner
Reviewed by:	adridg, jhale, rene, tcberner
Approved by:	portmgr (implicit, flavor hook)
Differential Revision:	https://reviews.freebsd.org/D17741

devel/boost-*: update to 1.68.0

- Switch to C++14 for libboost_system to support C++14 consumers

Changes:	http://www.boost.org/users/history/version_1_68_0.html
PR:		229569
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D16165

Replace bsd.qt.mk by Uses/qt.mk and Uses/qt-dist.mk

From now on, ports that depend on Qt4 will have to set
	USES=		qt:4
	USE_QT=		foo bar
ports depending on Qt5 will use
	USES=		qt:5
	USE_QT=		foo bar

PR:		229225
Exp-run by:	antoine
Reviewed by:	mat
Approved by:	portmgr (antoine)
Differential Revision:	-https://reviews.freebsd.org/D15540

devel/boost-*: update to 1.67.0

Changes:	http://www.boost.org/users/history/version_1_67_0.html
PR:		227427
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D15030

devel/boost-*: update to 1.66.0

Changes:	http://www.boost.org/users/history/version_1_66_0.html
PR:		223922
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D13279

multimedia/gstreamer-qt4, fix build with clang6

PR:		224945

devel/boost-*: update to 1.65.1

Changes:	http://www.boost.org/users/history/version_1_65_1.html
PR:		218835
Approved by:	maintainer timeout (1.65.1: 2 weeks; 1.65.0: 1 month)
Tested by:	jhibbits (on powerpc64, earlier version)
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D11582

devel/boost-*: enable C++11 features

PR:		218835
Obtained from:	https://github.com/DragonFlyBSD/DeltaPorts/pull/690
Approved by:	maintainer timeout (2 months)
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D11582

Make ninja opt-out in cmake.mk

Using ninja instead of make (1) can lead to significant speed ups while
building.
Therefore switch from having the ninja generator opt-in to having it opt-out.

Previously cmake-ports that wanted to use ninja could set
    CMAKE_NINJA=yes
now, ports that do not work with ninja can set
    cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.

The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary

PR:		219629
PR:		213331
Exp-run by:	antoine
Reviewed by:	rakuco
Differential Revision:	https://reviews.freebsd.org/D10748

devel/boost-*: update to 1.64.0

Changes:	http://www.boost.org/users/history/version_1_64_0.html
PR:		218835
Approved by:	office (bapt)
Exp-run by:	antoine
Differential Revision:	https://reviews.freebsd.org/D10472

devel/boost-*: update to 1.63.0

Changes:	http://www.boost.org/users/history/version_1_63_0.html
PR:		215598
Exp-run by:	antoine
Approved by:	office (bapt)
MFH:		2017Q1

Stop exporting QT_BINDIR and QT_LIBDIR to PLIST_SUB.

As at the moment QT_BINDIR and QT_LIBDIR are 'bin' respectively 'lib' depending
on the Qt version these subs ended up at many wrong places in plists.

So only export it if QT_DIST is set.

PR:		210227
Reviewed by:	mat, rakuco
Approved by:	portmgr (mat), rakuco (mentor)
Differential Revision:	https://reviews.freebsd.org/D8378

devel/boost-*: update to 1.62.0

- Enable `long double` C99 math usage
- Switch 9.x back to building with GCC

Changes:	http://www.boost.org/users/history/
PR:		199601
Submitted by:	Chen Xu, bapt, amdmi3, truckman (based on)
Reviewed by:	rakuco (kde) (earlier version)
Exp-run by:	antoine (3 tries), truckman (consumers only, earlier versions)
Approved by:	bapt (office)

Use USES=pathfix where applicable.

PR:		213195
Submitted by:	mat
Exp-run by:	antoine
Sponsored by:	Absolight
Differential Revision:	https://reviews.freebsd.org/D8093

Replace Mk/bsd.kde4.mk by Mk/Uses/kde.mk in preparation for KDE Frameworks and
Plasma5 ports

At the moment KDE ports use bsd.kde4.mk to handle their dependencies. When
working on the ports for KDE Frameworks and Plasma5 it seemed to be more
reasonable to create a new kde.mk instead of adding an bsd.kde5.mk.

The kde.mk in this review is a stripped down version of the one we are using in
the KDE Test repositories plasma5 branch [1] to only contain the parts relevant
to the current KDE4 ports in the portstree [2].

Changes to the KDE Ports needed by this:

Replace USE_KDE4 by USE_KDE [3]
Add USES=kde:4 [4]

Remove ${PORTSDIR}/ from dependencies, categories m, n, o, and p.

With hat:	portmgr
Sponsored by:	Absolight

qt4-moc: Add more Boost include guards to moc's definition list.

In preparation for updating Boost to 1.60, add include guards from more Boost
headers to the list of macros that moc automatically defines when processing
files. As explained in r408911, Qt4's moc cannot parse some constructs used by
a few Boost headers, so we define their include guards to make moc skip them.

This is a cleaner approach that allows us to largely revert r408472, r408473,
r408474, r408475, r408502, r408773 and r408419, which added several patches to
many ports to work around this moc bug.

PR:		199601
PR:		208322

Assign port to kde@.

kde@ already maintains multimedia/gstreamer1-qt4, and fluffy@ used to be part
of kde@ back in the day when this one was created.

- Fix build with boost 1.60

PR:		199601

Convert LICENSE= "GPLxx # or later" to "GPLxx+"

Approved by:	portmgr blanket

- Add LICENSE
- Silence patching

- Reassign to the heap after fluffy@'s bit was taken in for safekeeping

Remove UNIQUENAME and LATEST_LINK.

UNIQUENAME was never unique, it was only used by USE_LDCONFIG and now,
we won't have conflicts there.

Use PKGBASE instead of LATEST_LINK in PKGLATESTFILE, the *only* consumer
is pkg-devel, and it works just fine without LATEST_LINK as pkg-devel
has the correct PKGNAME anyway.

Now that UNIQUENAME is gone, OPTIONSFILE is too. (it's been called
OPTIONS_FILE now.)

Reviewed by:	antoine, bapt
Exp-run by:	antoine
Sponsored by:	Absolight
Differential Revision:	https://reviews.freebsd.org/D3336

- Drop @dirrm* from and add empty directories to pkg-plists

Approved by:	portmgr blanket

Update the default version of GCC in the Ports Collection from GCC 4.7.4
to GCC 4.8.3.

Part II, Bump PORTREVISIONs.

PR:		192025
Tested by:	antoine (-exp runs)
Approved by:	portmgr (implicit)

Convert a bunch of USE_BZIP2 to USES=tar:bzip2

Approved by:	portmgr (not really, but touches unstaged ports)

Chase boost and icu bump
While here convert some LIB_DEPENDS

Convert LIB_DEPENDS for ports depending on boost

- Argh! Install pkgconfig data to right place!

- Update to 0.10.3 stable release

- Replace QT_.*_REL with QT_.* in PLIST_SUB.
- Adapt plists.

With hat on:	kde

- Support staging.
- Convert to USES=gmake.

Submitted by:	Schaich Alonso <alonsoschaich@fastmail.fm> via our area51
repositor
Approved by:	fluffy (implicit)

Add NO_STAGE all over the place in preparation for the staging support (cat:
multimedia)

Add an explicit dependency on pkgconf

Approved by:	portmgr (bapt)

- convert USE_CMAKE to USES
- while here clean up some ports from CMAKE_VERBOSE, which is intended
  for users

Approved by:	portmgr (miwi)

Convert USE_BISON to USES= bison

It brings bison as a build dependency in case it is set the following way:
USES= bison or USES= bison:build

it brings bison as a run dependency in case it is set the following way:
USES= bison:run

it brings bison both as a run and build dependency in case it the set the
following way:
USES= bison:both

While here trim some headers
Convert some USE_GNOME= gnomehack to USES= pathfix

Chase boost update

- Use QT_LIBDIR_REL in plist.
- Set LATEST_LINK to avoid conflict with gstreamer's UNIQUENAME.
- Trim Makefile header.

With hat on:	kde
Feature safe:	yes

- Convert USE_QT_VER=4 and QT_COMPONETS to USE_QT4

Review by:      bapt, David Naylor (kde team)

- update png to 1.5.10

- Update GStreamer-Qt4 to 0.10.2 release

- Do not USE_GMAKE.

PR:             156527
Submitted by:   bapt

Require qtestlib only to build the port.

It is needed only to build the unit tests, so it does not make sense to depend
on it during run-time.

Approved by:    avilla (mentor)

Explicitly depend on qtestlib, which the buildsystem looks for.

Approved by:    makc (mentor), fluffy (maintainer, implicit)

- Add LDFLAGS to CONFIGURE_ENV and MAKE_ENV (as it was done with LDFLAGS)
- Fix all ports that add {CPP,LD}FLAGS to *_ENV to modify flags instead

PR:             157936
Submitted by:   myself
Exp-runs by:    pav
Approved by:    pav

CMAKE_BUILD_TYPE is set in bsd.cmake.mk now, remove it from Makefiles

- Add missed directory to plist

PR:             154550
Submitted by:   az
Feature safe:   yes

- Add gstreamer-qt4

This ports provide Qt4 media layer for GStreamer multimedia library

Feature safe:   yes