feature request: config option debugging tools #16
Labels
No labels
bug
crate/cli
crate/core
crate/parser
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
rokc/rokc#16
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I maintain the
pin-init-nexttree of the kernel. Every release, I check if my testing configs are up to date, as I want to compile-test all Rust code in the kernel. For this purpose, I'm currently usingmake menuconfigand then use its search functionality: pressing/and then typingRUSTto find all the options that mentionRUST(which is hopefully good enough to find most Rust code).This time, I again encountered a pretty annoying issue:
PWM_TH1520got added that uses Rust.menuconfig, I see that the driver cannot be enabled on my hardware. However, I still can compile-test it by enablingCOMPILE_TEST.COMPILE_TEST, my test script encountered the error thatCONFIG_RUSTis not enabled.depends onexpression ofRUSTis not enabled begins.makeconfigis a bit frustrating to work with in this regard:[=y]or[=n], when they are negated, so!OPTION [=y], I cannot remember the precedence of the[=?](I only use this feature once a release after all).a || b && c(which is a problem because I keep forgetting the precedence :)RANDSTRUCT.@kloenk repeatedly told me about this Kconfig parser that she is working on, so when I asked about this feature, she directed me here to add a feature request :)
Ideally, I would have a CLI that I can query for several pieces of information contained in my
.config:depends onexpression in a readable form forOPTION" including the information of which subexpressions arefalseand ultimately lead to the option not being availableOPTION" also with the addition of "that aren't enabled" to simplify the search for things that use Rust.The first part is most likely much simpler than the second and would already avoid a lot of the pain. The second one would make my work each release very easy.
https://cl.afnix.fr/c/rokc/rokc/+/636 implements a initial dependency graph. still planned but missing:
@bennolossin could you split of the reverse dependency feature request into a new issue, so that we can close this issue later and have the revers dependency still open?
@kloenk wrote in #16 (comment):
Thanks a lot for the quick impl! I tested it on my kernel tree and found it to be very useful indeed (it required a bit of hacking to get working). The only thing that I'm missing is the ability to limit the depth of the dependency expression. So only print the direct dependents of
RUSTand no transtitive ones, or print all transtitive dependencies up to a depth ofX.Here is an example of how it looks like (only a part of the RUST tree):
With only direct dependents, it would look like this instead:
@kloenk wrote in #16 (comment):
Done, created #17.
I tried the new versions a couple of days ago and the depth parameter is exactly what I need. I have a couple of improvement ideas:
(y)and(n)to make it easier to find the disabled option!and the expression, so!VALUEor!(V1 && V2)Thanks a lot for this!