[Peter]
> >You can also have a list of CONFIGs, can you not? In which case you
> >have a parsing problem either way.
[kaos]
> select() takes exactly one CONFIG_, select_cond() takes exactly two.
> No kbuild 2.5 command takes a variable sized list of CONFIGs.
OK, if you say multiple dependent CONFIG_ variables are not needed, I'm
happy to take your word for it.
> >I still don't see why the code can't just do as dep_tristate does: "if
> >there exists an 'n', return 'n', else if there exists an 'm', return
> >'m', else return 'y'".
> CONFIG_ISDN CONFIG_ISDN_PPP slhc.o
> n - n
> y n n
> y y y
> m n n
> m y m
Uh, I guess we're talking in circles, but AFAICT we are describing the
same truth table. The only difference is that your version may be
easier to do in a makefile, because you assume the second variable must
be a bool.
*If* we can assume that a 'n' variable will not be '' instead [yes, I
know, we can't assume that at present], the makefile implementation is
trivial:
ifeq(,$(findstring n,$(CONFIG_FOO)$(CONFIG_BAR))
ifneq(,$(findstring m,$(CONFIG_FOO)$(CONFIG_BAR)))
# compile as module
else
# compile builtin
endif
endif
> The first config has priority, the second only selects a subset.
If you can come up with an example where doing it your way with the
variables in the correct order (like your table above) produces a
different result than my algorithm with the variables in *either*
order, I promise to slap myself for being stupid, and then shut up.
Peter
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
