On Mon, 21 May 2007 03:43:45 +0200 (CEST) Roman Zippel wrote: > Hi, > > On Sun, 20 May 2007, Sam Ravnborg wrote: > > > I did a quick hack so kconfig could scan all Kconfig files > > in the kernel tree. > > By scanning all Kconfig files we gain the following: > > > > -> kconfig can report when a depends on refer to an undefined symbol > > -> kconfig can report when a select refer to an undefined symbol > > > > Later we can push a lot of common stuff to the top-level Kconfig file. > > And that may in the end result in a better structure overall for > > Kconfig files. > > Well, some of that stuff should already happen earlier (and included from > the arch Kconfig files), but that doesn't work for everything. > I don't think that simply allowing to parse a file multiple times is the > right answer, as it duplicates a lot of data. A simple example would be > help texts, right now they are per symbol, but they should really be per > menu, so archs can provide different help texts for something. > "source" should become a bit more intelligent and parse a file only once > and link the data into the menu structure. > > > All the "choice values currently only support a single prompt" are caused > > by using the same config symbol in a choice list for several architectures. > > That will be the biggest challenge to fix before we can introduce this > > patch. > > Maybe we can extend kconfig to accept it??? > > Define "accept". > The basic rule for choice values must not be violated - none of them may > depend on another value in the same group. The dependency tree allows for > no loops, these choice groups allow for the only exception, but it has to > stay within that group. > One option I'm thinking about is to extend that group by naming the choice > option, so kconfig knows they are related. This won't work for everything, > so quite some renaming may be needed.
how about something that I mentioned a few days ago (in another mail thread): Make this work: (-ENOPATCH) if S390 include "some s390-specific Kconfig file" endif and if ARCH!=S390, don't read that file. Actually it should be any kconfig-language statements inside the if-block /methinks. I understand that *conf treats all kconfig symbols as variable, but ARCH=blah isn't really variable after it has been set. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/