X11-TOOLKIT/QT5-GUI, no dbus

BSD-Kitsune

Active Member

Reaction score: 85
Messages: 208

As of yesterday I appear to have built it but haven't installed any supplementary ports to check it's operation.


Here's the version of it without devel/dbus support. If anyone's interested in a more complete thing or if there's a need to add these options upstream, then explain to me how we reconcile it. I'm not super familiar with big ports like this passing options into the binaries.
 

sidetone

Daemon

Reaction score: 921
Messages: 1,883

Did you get a response from emailing the maintainer?

A diff -u between the original Makefile and edited Makefile sent to them will help.

How about one with a radio or single option, to select it with make config. That way, it won't interfere with the way they intend to have it work, and it can be easily tested by deselecting dbus. I may try this, this week, and post the diff -u.
 

sidetone

Daemon

Reaction score: 921
Messages: 1,883

This is an attempt to make DBUS an option that can be selected by the user for x11-toolkits/qt5-gui. The diff -u is from the original Makefile.
Code:
--- Makefile.orig       2021-10-01 07:16:46.714179000 +0000
+++ Makefile    2021-10-01 07:39:08.581456000 +0000
@@ -14,8 +14,7 @@
                ${BUILD_DEPENDS_${ARCH}}
 BUILD_DEPENDS_armv6=   as:devel/binutils
 BUILD_DEPENDS_armv7=   as:devel/binutils
-LIB_DEPENDS=   libdbus-1.so:devel/dbus \
-               libevdev.so:devel/libevdev \
+LIB_DEPENDS=   libevdev.so:devel/libevdev \
                libfontconfig.so:x11-fonts/fontconfig \
                libfreetype.so:print/freetype2 \
                libharfbuzz.so:print/harfbuzz \
@@ -36,7 +35,7 @@
                        qmake:no_env qt-dist:5,base
 USE_GL=                        egl gl
 USE_GNOME=             glib20
-USE_QT=                        core dbus network buildtools_build qmake_build
+USE_QT=                        core network buildtools_build qmake_build
 QT_BINARIES=           yes
 QT_CONFIG=             accessibility accessibility-atspi-bridge dbus \
                        fontconfig glib opengl png system-freetype system-jpeg \
@@ -57,12 +56,14 @@
 BUILD_WRKSRC=  ${WRKSRC}/src/${PORTNAME}
 INSTALL_WRKSRC=        ${BUILD_WRKSRC}
 
-OPTIONS_DEFINE=                X11
-OPTIONS_DEFAULT=       X11
+OPTIONS_DEFINE=                X11 DBUS
+OPTIONS_DEFAULT=       X11 DBUS
 OPTIONS_SUB=           yes
 
 X11_USES=      xorg
 X11_USE=       xorg=x11
+DBUS_LIB_DEPENDS=      libdbus-1.so:devel/dbus
+DBUS_USE=      QT=dbus
 
 # Build and install QtPlatformSupport and default QPA plugins (XCB,
 # minimal and offscreen). QtGui won't work without (one of) them, but

These following lines were taken care of, and turned into options, to only be used when DBUS is chosen in the diff above.
Code:
LIB_DEPENDS=    libdbus-1.so:devel/dbus \
USE_QT=            core dbus network buildtools_build qmake_build
The following lines are the ones I couldn't figure out how to remove DBUS from hardset requirements, to include it into the option.
Code:
QT_CONFIG=        accessibility accessibility-atspi-bridge dbus \
QT_DEFINES=        ACCESSIBILITY DBUS FONTCONFIG FREETYPE GLIB \
An if/then statement can be used if DBUS is selected, or I don't know if it can possibly be included into the DBUS_USE= line. These two lines reference within /usr/ports/Mk/Uses/. When this part is figured out, it can be submitted to the maintainer. An if/then statement when DBUS is selected may be the best way to complete the last steps.
 

sidetone

Daemon

Reaction score: 921
Messages: 1,883

Here, I used an if-then statement, to take care of the remaining parts of QT_CONFIG= and QT_DEFINES=. This is the diff -u between the original and adjusted Makefile. This adjustment turns dbus into an option, to make it simpler for those who wish to test this port without it.
Code:
--- Makefile.orig       2021-10-01 07:16:46.714179000 +0000
+++ Makefile    2021-10-01 22:44:22.847818000 +0000
@@ -14,8 +14,7 @@
                ${BUILD_DEPENDS_${ARCH}}
 BUILD_DEPENDS_armv6=   as:devel/binutils
 BUILD_DEPENDS_armv7=   as:devel/binutils
-LIB_DEPENDS=   libdbus-1.so:devel/dbus \
-               libevdev.so:devel/libevdev \
+LIB_DEPENDS=   libevdev.so:devel/libevdev \
                libfontconfig.so:x11-fonts/fontconfig \
                libfreetype.so:print/freetype2 \
                libharfbuzz.so:print/harfbuzz \
@@ -36,13 +35,13 @@
                        qmake:no_env qt-dist:5,base
 USE_GL=                        egl gl
 USE_GNOME=             glib20
-USE_QT=                        core dbus network buildtools_build qmake_build
+USE_QT=                        core network buildtools_build qmake_build
 QT_BINARIES=           yes
-QT_CONFIG=             accessibility accessibility-atspi-bridge dbus \
+QT_CONFIG=             accessibility accessibility-atspi-bridge \
                        fontconfig glib opengl png system-freetype system-jpeg \
                        system-png xcb xcb-glx xcb-render xcb-xlib xinput2 xlib \
                        xrender
-QT_DEFINES=            ACCESSIBILITY DBUS FONTCONFIG FREETYPE GLIB \
+QT_DEFINES=            ACCESSIBILITY FONTCONFIG FREETYPE GLIB \
                        IMAGEFORMAT_PNG OPENGL SHAPE XCB XKB XKBCOMMON XRENDER
 USE_XORG=              ice sm xi xrender
 HAS_CONFIGURE=         yes
@@ -57,12 +56,14 @@
 BUILD_WRKSRC=  ${WRKSRC}/src/${PORTNAME}
 INSTALL_WRKSRC=        ${BUILD_WRKSRC}
 
-OPTIONS_DEFINE=                X11
-OPTIONS_DEFAULT=       X11
+OPTIONS_DEFINE=                X11 DBUS
+OPTIONS_DEFAULT=       X11 DBUS
 OPTIONS_SUB=           yes
 
 X11_USES=      xorg
 X11_USE=       xorg=x11
+DBUS_LIB_DEPENDS=      libdbus-1.so:devel/dbus
+DBUS_USE=      QT=dbus
 
 # Build and install QtPlatformSupport and default QPA plugins (XCB,
 # minimal and offscreen). QtGui won't work without (one of) them, but
@@ -113,3 +114,8 @@
 .endfor
 
 .include <bsd.port.mk>
+
+.if ${PORT_OPTIONS:MDBUS}
+QT_CONFIG+=    dbus
+QT_DEFINES+=   DBUS
+.endif

This diff got sent to the maintainer. (Update - it took getting on the https://mail.kde.org/mailman/listinfo/kde-freebsd mailing list for the message to pass through, otherwise it's put on hold and could get blocked.)

 

sidetone

Daemon

Reaction score: 921
Messages: 1,883

I got a response, to add <bsd.port.options.mk> to the bottom. Also, there was a suggested replacement for the if-then statement.
Code:
--- Makefile.orig       2021-10-04 20:16:17.706647000 +0000
+++ Makefile    2021-10-04 20:23:18.678333000 +0000
@@ -14,8 +14,7 @@
                ${BUILD_DEPENDS_${ARCH}}
 BUILD_DEPENDS_armv6=   as:devel/binutils
 BUILD_DEPENDS_armv7=   as:devel/binutils
-LIB_DEPENDS=   libdbus-1.so:devel/dbus \
-               libevdev.so:devel/libevdev \
+LIB_DEPENDS=   libevdev.so:devel/libevdev \
                libfontconfig.so:x11-fonts/fontconfig \
                libfreetype.so:print/freetype2 \
                libharfbuzz.so:print/harfbuzz \
@@ -36,13 +35,13 @@
                        qmake:no_env qt-dist:5,base
 USE_GL=                        egl gl
 USE_GNOME=             glib20
-USE_QT=                        core dbus network buildtools_build qmake_build
+USE_QT=                        core network buildtools_build qmake_build
 QT_BINARIES=           yes
-QT_CONFIG=             accessibility accessibility-atspi-bridge dbus \
+QT_CONFIG=             accessibility accessibility-atspi-bridge \
                        fontconfig glib opengl png system-freetype system-jpeg \
                        system-png xcb xcb-glx xcb-render xcb-xlib xinput2 xlib \
                        xrender
-QT_DEFINES=            ACCESSIBILITY DBUS FONTCONFIG FREETYPE GLIB \
+QT_DEFINES=            ACCESSIBILITY FONTCONFIG FREETYPE GLIB \
                        IMAGEFORMAT_PNG OPENGL SHAPE XCB XKB XKBCOMMON XRENDER
 USE_XORG=              ice sm xi xrender
 HAS_CONFIGURE=         yes
@@ -57,13 +56,17 @@
 BUILD_WRKSRC=  ${WRKSRC}/src/${PORTNAME}
 INSTALL_WRKSRC=        ${BUILD_WRKSRC}
 
-OPTIONS_DEFINE=                X11
-OPTIONS_DEFAULT=       X11
+OPTIONS_DEFINE=                X11 DBUS
+OPTIONS_DEFAULT=       X11 DBUS
 OPTIONS_SUB=           yes
 
 X11_USES=      xorg
 X11_USE=       xorg=x11
 
+DBUS_LIB_DEPENDS=      libdbus-1.so:devel/dbus
+DBUS_USE=              QT=dbus
+DBUS_VARS=             QT_CONFIG+=dbus QT_DEFINES+=DBUS
+
 # Build and install QtPlatformSupport and default QPA plugins (XCB,
 # minimal and offscreen). QtGui won't work without (one of) them, but
 # they depend on QtGui itself, so they can't be added as dependencies.
@@ -113,3 +116,4 @@
 .endfor
 
 .include <bsd.port.mk>
+.include <bsd.port.options.mk>
If I understand correctly, suggested edits can be sent to be reviewed at https://deref-mail.com/mail/client/H77agQHcC7s/dereferrer/?redirectUrl=https://reviews.freebsd.org/
 

astyle

Daemon

Reaction score: 629
Messages: 1,432

Removing the tightly interwoven dependencies like this is generally a good idea... but if you don't like DBus, is there an alternative to the IPC that QT needs to have access to?
 

sidetone

Daemon

Reaction score: 921
Messages: 1,883

There's not that I know of. It doesn't hurt for those who want to try it without dbus. For those, it's better that it's an option, so it's uniform and testing it becomes simpler. A lot still works, in the past even faster without dbus.

Still, it was a good learning exercise for me. I also believe that, making more dependencies into options will be the start of a way the Ports tree gets cleaned up and improved. It will show, which ones pull in unnecessary dependencies. By making it an option, it won't hurt anything for those who use the default settings.

I forgot, that there was mention of masking of dbus in plist when it's changed from a hardset dependency. It has been sent to Bugzilla, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258953.

I may get a Phabricator account at another time. That would be helpful for future edits/trials.
 
OP
BSD-Kitsune

BSD-Kitsune

Active Member

Reaction score: 85
Messages: 208

Hi there Sidetone,

Sorry for the delay, as I mentioned in another thread I was sick and also preoccupied. Life stuff.

This looks better than I could have imagined. Good job. We can definitely benefit if this gets upstreamed. It may be good to push the FreeBSD-KDE ML to the existence of the bug, so we can get it upstreamed. I can probably do it sooner or later.
 

Zirias

Son of Beastie

Reaction score: 1,698
Messages: 2,869

I got a response, to add <bsd.port.options.mk> to the bottom. Also, there was a suggested replacement for the if-then statement.
Don't do both, you can remove this last line again.

In general, you include <bsd.port.options.mk> before you check any options-related variables. <bsd.port.mk> must stay at the very bottom. Most of the time, doing this is unnecessary because the ports framework offers a lot of options-related helpers, see for example here a list of variables that understand the <option>_FOO and <option>_FOO_OFF variants: https://docs.freebsd.org/en/books/porters-handbook/makefiles/#options-variables

Did you check whether this change also influences pkg-plist?

Also, just using diff(1) will always work, but if you do changes more often and/or more complex changes, you'd profit a lot from learning to use git instead. It will take time to learn, but then it's much easier than manually fiddling with diff(1).

On the topic: A KDE Desktop uses dbus a lot, so will never work without it. But as for this change, it makes sense that the gui part of qt doesn't have to depend on dbus.
 
OP
BSD-Kitsune

BSD-Kitsune

Active Member

Reaction score: 85
Messages: 208

Yes, but obviously we're talking about for QT PROGRAMS, not DEs

I'm not building GNOME or KDE, and as I've said unpopularly -- i think we should give up on packaging/porting them and reallocate our forces elsewhere. But as these are volunteers, you can't bark orders at people.
 

sidetone

Daemon

Reaction score: 921
Messages: 1,883

That's a relevant point. It's useful for those who want to try it out and don't use KDE. It's an important note for those who do use KDE. They'll use it anyway, and I'm for it remaining as default.

It's partly why I wanted to make it an option, so it can be tried without breaking functionality for those who need it for something, or risking functionality for port sets that may rely on it.

I'm not building GNOME or KDE, and as I've said unpopularly -- i think we should give up on packaging/porting them and reallocate our forces elsewhere. But as these are volunteers, you can't bark orders at people.
We need to learn about it, and improve our understanding of porting and helping with patches. Use options as a way of suiting different camps of thought. Using options in the wrong places could increase complexity. When an option isn't needed, for the port to work at all, the option is better as an option than a hardset dependency. When it comes to basic use without a desktop environment, it will decrease complexity. I'm slowly learning how to apply what's needed to achieve this through ports.
 
OP
BSD-Kitsune

BSD-Kitsune

Active Member

Reaction score: 85
Messages: 208

That's a relevant point. It's useful for those who want to try it out and don't use KDE. It's an important note for those who do use KDE. They'll use it anyway, and I'm for it remaining as default.

It's partly why I wanted to make it an option, so it can be tried without breaking functionality for those who need it for something, or risking functionality for port sets that may rely on it.


We need to learn about it, and improve our understanding of porting and helping with patches. Use options as a way of suiting different camps of thought. Using options in the wrong places could increase complexity. When an option isn't needed, for the port to work at all, the option is better as an option than a hardset dependency. When it comes to basic use without a desktop environment, it will decrease complexity. I'm slowly learning how to apply what's needed to achieve this through ports.

My view is along the same sort of lines -- I wanted to make it an option but it's a lot harder with big ports like this than smaller ones, so I didn't know how.

Additionally, for me, I'm pretty anti-GNOME/KDE/XFCE etc. If I had it my way, we'd only focus on our stuff.

The fact that Lumina can't be built currently without dbus is a crying shame.
 
OP
BSD-Kitsune

BSD-Kitsune

Active Member

Reaction score: 85
Messages: 208

I attempted Sidetone's patches and it didn't work. I tried finagling some more, it's still failing.

Here's my current makefile (it's not an option here, just trying to get a raw build of it to work without dbus first.

Not sure where to go, but it's absolutely possible to straight up build qt5 without dbus.
 

Attachments

  • Makefile.txt
    3.7 KB · Views: 6
Top