On 3/24/24 01:00, Oliver Webb wrote: > I've done some research on this too, we have no "select" statements in any of > our config symbols,
for a definition of "we" that is "I have intentionally not merged any", since I review and approve all the kconfig command sections in the headers and have been tracking that. (At one point the config2help.c stuff was trying to stitch dependencies together to merge help text, and didn't understand complicated syntax.) That said, forking the kconfig language definition is not something I do lightly. Ours has fallen way behind the kernel's, and thus looks like something else but is only compatible with a subset of it. We are about to _shrink_ that subset. This needs a FAQ entry at least. > but we do have a fair amount of that ""SYMBOL && (SYMBOL||SYMBOL)"" > expression processing that's > annoying to deal with. I was referring to that, yes. I need to implement processing for it. I've already implemented such processing in find, test, and twice in toysh (both command && command and $((math&&math)) ). > Also a "choice" block and a few number ranges in the main Config.in we will > need to deal with in some way, the depends/selects stuff seems easy but with > that expr evaluating probably isn't Yes, I know. > I tried to write a kconfig parser (As a toy to make the codesharing easier) I've written at a bunch, and mostly thrown them away again. There's a simple one in scripts/config2help.c and wrote one in python at https://landley.net/hg/kdocs/file/tip/make/menuconfig2html.py which generated https://landley.net/kdocs/menuconfig/ way back when. (Those are the only two published ones that come to mind, but I've written more over the years.) > and got absolutely nowhere. The approach I took to it was... This isn't the hard part. To me, the hard part is wanting to share lib/*.c code with this new binary, which implies it would live in toys/example/*.c, which means in the NEW design it would be a normal command that's "default n"... and maybe depends on TOYBOX_BUILD or some such? Except moving stuff from scripts/*.c to toys/*.c is conceptually ugly. But if we're getting rid of the subdirectories... Maybe make.sh needs to be able to build commands that DON'T live in toys/ but then... Unanswered design questions looming here, have not been jigsawed into an elegant picture yet. (How much of that is assembling pieces and how much is SAWING THEM UP I don't know yet...) Anyway, it seems like config2help.c should also share this plumbing if it's parsing the kconfig input anyway, which is convenient since I've been meaning to rewrite all that too (and yes THAT has a motivating "somebody is waiting for me to fix this", ala https://github.com/landley/toybox/issues/458 ), but there's also the usage: line regularization (https://landley.net/notes-2023.html#06-11-2023) and fixing the remaining sub-options with maybe some sort of help text include syntax for inserting other help texts at controllable points (as either blogged about or mentioned here on the list, I'd have to check my notes to see where I left off on that)... Once I've got the design worked out, coding it is usually the easy part. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
