aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/kconfig/gconf.c
Commit message (Collapse)AuthorAge
* kconfig: gconfig: symbol fixEGRY Gabor2008-01-28
| | | | | | | | | Gettext support for symbol names are unnecessary. Signed-off-by: Egry Gabor <gaboregry1@t-online.hu> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
* kconfig: missing macros in gconfigEGRY Gabor2008-01-28
| | | | | | | | | This patch adds missing gettext macros. Signed-off-by: Egry Gabor <gaboregry1@t-online.hu> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
* kconfig: delete unused FILE_ and SYMBOL_ flagsSam Ravnborg2008-01-28
| | | | | | | | The *_PRINTED flags were never used - so delete them. Do we need them later then we can re-add them. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
* kconfig: attach help text to menusSam Ravnborg2007-07-25
| | | | | | | | | | | | | | | Roman Zippel wrote: > 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. This patch does this and at the same time introduce a few API funtions used to access the help text. The relevant api functions are introduced in the various frontends. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org>
* [PATCH] kconfig: set gconf's save-widget's sensitivity according to ↵Karsten Wiese2006-12-13
| | | | | | | | | | | | | .config's changed state Clean up a little. Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Roman Zippel <zippel@linux-m68k.org> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* kconfig: allow loading multiple configurationsRoman Zippel2006-06-09
| | | | | | | | Extend conf_read_simple() so it can load multiple configurations. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* kconfig: remove SYMBOL_{YES,MOD,NO}Roman Zippel2006-06-09
| | | | | | | | | The SYMBOL_{YES,MOD,NO} are not really used anymore (they were more used be the cml1 converter), so just remove them. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* kbuild: create .kernelrelease at *config stepSam Ravnborg2006-01-16
| | | | | | | | | | | | To enable 'make kernelrelease' earlier now create .kernelrelease when one of the *config targets are used. Also introduce KERNELVERSION - only user is kconfig. KERNELVERSION was needed to display kernel version in menuconfig - KERNELRELEASE is not valid until configuration has completed. kconfig files modified to use KERNELVERSION. Bug reported by: Rene Rebe <rene@exactcode.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* [PATCH] fix gconfig crashJoachim Nilsson2005-07-28
| | | | | | | | | | | | | | | I ran glade-2 on the glade file, fixed two missing stock icons and cleaned up the C code that inserts the single/split/full modes. The rest of the patch is minor cleanups only. I refrained from using all the included xpm icons in images.c (like qconf.cc does) in favour of using the stock Gtk+ icons instead. Oh, yes there was a "back" bug in split mode that I also removed, oh well... It has been tested with success by several people, including Jesper Juhl, Randy Dunlap and myself. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Kconfig i18n supportArnaldo Carvalho de Melo2005-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds i18n support for make *config, allowing users to have the config process in their own language. No printk was harmed in the process, don't worry, so all the bug reports, kernel messages, etc, remain in english, just the user tools to configure the kernel are internationalized. Users not interested in translations can just unset the related LANG, LC_ALL, etc env variables and have the config process in plain english, something like: LANG= make menuconfig is enough for having the whole config process in english. Or just don't install any translation file. Translations for brazilian portuguese are being done by a team of volunteers at: http://www.visionflex.inf.br/kernel_ptbr/pmwiki.php/Principal/Traducoes To start the translation process: make update-po-config This will generate the pot template named scripts/kconfig/linux.pot, copy it to, say, ~/es.po, to start the translation for spanish. To test your translation, as root issue this command: msgfmt -o /usr/share/locale/es/LC_MESSAGES/linux.mo ~/es.po Replace "es" with your language code. Then execute, for instance: make menuconfig The current patch doesn't use any optimization to reduce the size of the generated .mo file, it is possible to use the config option as a key, but this doesn't prevent the current patch from being used or the translations done under the current scheme to be in any way lost if we chose to do any kind of keying. Thanks to Fabricio Vaccari for starting the pt_BR (brazilian portuguese) translation effort, Thiago Maciera for helping me with the gconf.cc (QT frontent) i18n coding and to all the volunteers that are already working on the first translation, to pt_BR. I left the question on whether to ship the translations with the stock kernel sources to be discussed here, please share your suggestions. Signed-off-by: Arnaldo Carvalho de Melo <acme@conectiva.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org Signed-off-by: Andrew Morton <akpm@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!