[Kai Germaschewski] > Seeing it from that point of view, it may actually turn into > something which can agree with much more easily.
Great! I've been hoping for your support - not only because I respect your judgment, but also because Linus takes patches from you. (: > Maybe it actually suffices to declare if_dep, fi_dep as "virtually > adds the listed arguments to each statement in the enclosed > region". Maybe there would be a better name for that, then if_dep, > OTOH using if_dep makes it quite clear what else_dep does. OK.. > Make every statement accepts dependencies (and depreciate the dep_ > prefixes, since they become unnecessary). There really isn't any > reason for the difference between bool and dep_bool right now, it > only leads to confusion and mistakes. I've proposed this in the past - well, at least the part about making bool == dep_bool or dep_mbool, and tristate == dep_tristate. I was going to raise the issue again, after the if_dep debate settled down some. > I didn't look into like choice statements, but I'd hope it's > possible to add dependencies to them, too, for consistency. I agree. Actually, if we're changing 'choice' anyway, it should be redesigned. Status quo takes three arguments: choice 'prompt string' 'choice-text-1 CONFIG_CHOICE1 choice-text-2 CONFIG_CHOICE2' 'choice-text-default' This is bad because it pretty much requires multi-line strings, and because the choice texts cannot have spaces in them. In my opinion it should take a variable number of args: choice 'prompt string' 'choice text 1' CONFIG_CHOICE1 'choice text 2' CONFIG_CHOICE2 CONFIG_CHOICE_DEFAULT I suppose you could then extend it with dependencies by putting those at the end. That makes for minor parsing problems, since you have to detect which arguments are which - basically I guess you look for two CONFIG_* in a row. Alternatively, we could make the parsing job a little less fragile by using an explicit keyword like 'dep': choice 'prompt' 'text 1' CONFIG_1 'text 2' CONFIG_2 'text 3' CONFIG_3 CONFIG_1 dep CONFIG_ISA !CONFIG_ARM Translation: CONFIG_1 is the default, but the prompt is suppressed if CONFIG_ISA is unset, or if CONFIG_ARM is set. Eh? > Extend the normal dep_* dependencies (now just called *) to accept > the same kind of dep lines as if_dep, i.e. !, =[ymn], !=[ymn], 'or', > 'and'. Already in my patches. Actually, I don't have an 'and' (Greg asked about this too), for two reasons. First, adjacent words are implicitly ANDed together anyway, so there's no need. Second, since OR takes low precedence and the implicit AND takes high precedence, having an explicit 'and' keyword would generate confusion about its precedence with regards to 'or'. I already rejected trying to do any sort of grouping - mostly because the shell parsers would choke on ( ) and nothing else looks as nice - so, since there is no way to group things, the precedence table needs to be as simple and clear as possible. I think my current proposal fits the bill. > Also, when doing that conversion, I think it may be worthwhile to get rid > of the distinction between mbool and bool by something like, changing > > dep_mbool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS >$CONFIG_ISDN_CAPI_CAPI20 > > to > > bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI!=n > > I think a sensible default would be m -> y in this case (like > mbool) That's the current default for if_dep already. I do not know if it is worthwhile to add a "!=" operator to complement the "=" operator, but perhaps it is, if only because people will expect it. I'll go ahead and add it to my Menuconfig patch, at least for now. It should be noted that in many cases, this whole distinction is unimportant, because the guard symbol (for example CONFIG_ISA) is already boolean. > I'd be interested to see if these statements are actually sufficient > to express all we've got today. [...] > Oh well, I think the only way to find out if all that is really a > good idea is to try, convert some config.in's and look at the > result. Right. I'll try to find the time to convert a few large Config.in / config.in files today, and post a patch (along with my current version of Menuconfig). Speaking of which - would it help anyone evaluate this stuff if I produced a patched Configure to complement the patched Menuconfig? I haven't been hacking on Configure, because for my purposes, stuff is easier to test with Menuconfig. (I added a line to init/Config.in that does "source test.in", so I can easily put tests in $(TOPDIR)/test.in. Works great.) > (The CONFIG_FOO=n case would still run through the statements > included by if_dep / fi_dep, automatically setting all vars to 'n', > since one of their deps is 'n') Reasonable people can disagree on this one. '' today means the user has never seen the question, so you would be changing existing semantics. I for one am fine with that, but others will probably argue for the status quo. According to MEC, Linus once said, "There are no default values, only default answers to questions." If a question is never asked, the value is never set. This property is used in 'make oldconfig', for one, although your proposed change wouldn't directly affect oldconfig. > OTOH, one of the problems I can see already is that > > bool '...' CONFIG_FOO > if [ "$CONFIG_FOO" = "y" ]; then > bool '...' CONFIG_BAR > [...] > else > define_bool CONFIG_BAR y > fi > > doesn't translate well. else_dep, in its current implementation, means "execute this block if and only if we didn't execute the previous block". I see no reason to change it - those semantics, to me, are simple and logical. Peter ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
