Two odd ebuild questions

[miket]

I have two questions about ebuilds that I don't see in the documentation. I could try some ad-hoc approaches, but I'd like to hear about what what would be the best approach.

1. Configuring a package where a --with/--without option which depends on more than one USE flag. Specifically, in src_configure() I'd like to set --with-qt or --without-qt if either the qt5 or qt6 flag is set.

Obviously, this simplistic approach would not work:

Code: Select all

local confargs=(
   $(use_enable something)
   $(use_with qt5 qt)
   $(use_with qt6 qt)
)

since it would often generate conflicting settings. A basic way around this would appear to be:

Code: Select all

local confargs=(
   $(use_enable something)
)
use qt6 || use qt5 && confargs+=(--with-qt) || confargs+=(--without-qt)

but I have my doubts. What is the best practice?

2. Setting an environment variable for the configure script. Also in src_configure(), I'd like to pass an environment variable to the configure script. The econf helper does not have a mechanism for setting environment variables, and the upstream configure script does not expose a way to set the value except by an enviroment variable. Should I export the variable inside of src_configure? Is

Code: Select all

ENVVAR="something" econf ...

a valid approach?

[logrusx]

https://devmanual.gentoo.org/ebuild-wri ... index.html should answer 1

and yes, you can do that for 2.

Regarding 1, you can also set exactly one of condition, but I don't know where/if there is documentation for that, but certainly there are ebuilds which terminate if more than one of a set of use flags is set or if one requires another, which is not set.

EDIT: check this ebuild: /var/db/repos/gentoo/app-i18n/fcitx-qt/fcitx-qt-5.1.9.ebuild and look for REQUIRED_USE
EDIT2: here it is: https://devmanual.gentoo.org/ebuild-wri ... quired_use

Best Regards,
Georgi

[John R. Graham]

...Regarding 1, you can also set exactly one of condition, but I don't know where/if there is documentation for that, but certainly there are ebuilds which terminate if more than one of a set of use flags is set or if one requires another, which is not set.

Documentation for all of the dependency specifications, including the "exactly one of" construct, is available in the Package Manager Specification, itself available through app-doc/pms.

- John

[miket]

...Regarding 1, you can also set exactly one of condition, but I don't know where/if there is documentation for that, but certainly there are ebuilds which terminate if more than one of a set of use flags is set or if one requires another, which is not set.

Documentation for all of the dependency specifications, including the "exactly one of" construct, is available in the Package Manager Specification, itself available through app-doc/pms.

Well, I did already know about the exactly-one-of dependency condition, but that wasn't of any help to me. I was aiming at another of those ebuilds that allow either or both of qt5 or qt6 to be set with the automatic selection of qt6 if both are present. Also, dependency expressions are not available in normal Bash code.

I found that my

Code: Select all

use qt5 || use qt6 && confargs+=(--with-qt) || confargs+=(--without-qt)

construct worked just fine--and so did an export directive. In the end, I took a more standard-looking approach and combined the two:

Code: Select all

local qtarg='--without-qt'
if use qt6; then
    qtarg='--with-qt'
    export QMAKE=$(which qmake6)
elif use qt5; then
    qtarg='--with-qt'
    export QMAKE=$(which qmake5)
fi
confargs+=("$qtarg")

(Yes, I found that specifying qmake5 or qmake6 is indeed enough to select the needed Qt slot.)

So here is what all this is about: I was having issues with net-misc/dhcpcd-ui and was trying to sort them out. Main problem: after a time (and, I suspect, after switching the network connection from wired to wireless and back to wired), dhcpcd-qt would peg a CPU core, dragging down the machine's performance and making it hot. A secondary problem was cosmetic: the status bar displayed a empty space rather than an icon when the connection was wired.

I put in debugging statements and changed icon names in the program in an attempt to track down where the CPU use was going up. I didn't find the CPU-use problem, but I did observe that when the program displayed an actual icon for the wired connection that the CPU-usage problem went away. This leads to a theory that the CPU use was related to trying to display a non-existent icon, but I'm not conviced. What I did see is that the hacky way the ebuild worked kept the makefile from building application-specific icons that the program displays (or attempts to display) when the current icon theme lacks an icon. This is where setting the QMAKE variable comes in--setting that variable and removing the hack now lets the build system populate icons under /usr/share/dhcpcd/icons/ as it should.

Since I was now setting QMAKE, I thought about going ahead to prepare this package for using QT6. After adjusting the package's dependencies, that worked--almost. I had to patch two files to make Qt6 happy.

At this point, I'm not completely convinced I've solved the CPU-heating problem. If things seem stable by next week after I've tried several configurations, I'll submit my dhcpcd-ui patches to Roy Marples. Just to note, this summarizes what they are: 1. in src/dhcpcd-qt/dhcpcd-qt.pro, change c++11 to c++17 and 2. in src/dhcpcd-qt/dhcpcd-ssid.cpp change QString::Null() to QString(). My ebuild currently applies the patch only when qt6 is active. I have yet to test whether the patch works properly when USE=qt5.

[logrusx]

It's best to report such bugs upstream rather than playing dice.

Best Regards,
Georgi