Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Jun 2017 09:28:20 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 220045] [NEW PORT] split part of www/qt5-websockets into new port www/qt5-websockets-qml
Message-ID:  <bug-220045-13-nFIkusZ8xi@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-220045-13@https.bugs.freebsd.org/bugzilla/>
References:  <bug-220045-13@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220045

--- Comment #4 from groot@kde.org ---
I'll quote some things from kenmoore in IRC for context:

<kenmoore>: Quick Question: Why does the qt5-websocket port require the
qt5-quick port? QtQuick is a graphical tool and brings in all the widgets/e=
tc,
but websocket is purely a CLI/core module: (reference:
http://www.freshports.org/www/qt5-websockets/) I just noticed that our "ser=
ver"
utility was sucking in all of X11 and tracked it down to the Qt5-websocket
port.

That's the question behind it: if you want to use qt5 websockets from a
text-only, command-line, QtCoreApplication, the existing port pulls in the =
core
bits for websockets, but also the QML bindings which add the whole QtGui st=
ack.
That's not-so-convenient for a text application, just in terms of what gets
installed alongside.

Debian has packages that allow installing the core parts separately from the
QML bindings (which pull in the GUI stack). So this split mirrors what Debi=
an
already do, and is convenient for those downstream consumers of Qt5 on Free=
BSD
that want websockets, without the GUI.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220045-13-nFIkusZ8xi>