Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Two odd ebuild questions
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 501
Location: Gainesville, FL, USA

PostPosted: Fri Mar 21, 2025 3:20 pm    Post subject: Two odd ebuild questions Reply with quote

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:

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:
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:
ENVVAR="something" econf ...
a valid approach?
Back to top
View user's profile Send private message
logrusx
Advocate
Advocate


Joined: 22 Feb 2018
Posts: 2872

PostPosted: Fri Mar 21, 2025 3:39 pm    Post subject: Reply with quote

https://devmanual.gentoo.org/ebuild-writing/use-conditional-code/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-writing/variables/#required_use

Best Regards,
Georgi
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10756
Location: Somewhere over Atlanta, Georgia

PostPosted: Fri Mar 21, 2025 3:46 pm    Post subject: Reply with quote

logrusx wrote:
...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
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 501
Location: Gainesville, FL, USA

PostPosted: Sat Mar 22, 2025 2:17 am    Post subject: Reply with quote

John R. Graham wrote:
logrusx wrote:
...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:
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:
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.
Back to top
View user's profile Send private message
logrusx
Advocate
Advocate


Joined: 22 Feb 2018
Posts: 2872

PostPosted: Sat Mar 22, 2025 6:26 am    Post subject: Reply with quote

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

Best Regards,
Georgi
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum