Use gperf to generate a hash for the kconfig keywords. This greatly reduces
the size of the generated scanner and makes it easier to extend kconfig.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When doing its recursive dependency check, scripts/kconfig/conf uses the flag
SYMBOL_CHECK_DONE to avoid rechecking a symbol it has already checked.
However, that flag is only set at the top level, so if a symbol is first
encountered as a dependency of another symbol it will be rechecked every time
it is encountered until it's encountered at the top level.
This patch adjusts the flag setting so that each symbol will only be checked
once, regardless of whether it is first encountered at the top level, or while
recursing down from another symbol. On complex configurations, this vastly
speeds up scripts/kconfig/conf. The config in the powerpc merge tree is
particularly bad: this patch reduces the time for 'scripts/kconfig/conf -o
arch/powerpc/Kconfig' by a factor of 40 on a G5. That's even including the
time to print the config, so the speedup in the actual checking is more likely
2 or 3 orders of magnitude.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Replace all menu_add_prop mimicking menu_add_prompt with the latter func. I've
had to add a return value to menu_add_prompt for one usage.
I've rebuilt scripts/kconfig/zconf.tab.c_shipped by hand to reflect changes
in the source (I've not the same Bison version so regenerating it wouldn't
have been not a good idea), and compared it with what Roman itself did some
time ago, and it's the same.
So I guess this can be finally merged.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Roman Zippel