| Message ID | 1353542766-24422-4-git-send-email-yann.morin.1998@free.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Yann. On Thu, Nov 22, 2012 at 01:06:06AM +0100, Yann E. MORIN wrote: > Currently, the root-menu label is hard-coded in the kconfig frontends > executables. This means that two projects that use kconfig and want > to display different root-menu labels can not share the same kconfig > frontends. > > Instead of hard-coding the label in the frontends, handle it the same > we handle the CONFIG_ prefix: > - get the root-menu label from the environment if present > - allow to set it at build time (eg. -DROOTMENU='"Root menu label"') > - fallback to a hard-coded default I have note paid attention to these CONFIG_ patches - and only now I took a short look at this set and I am not soo hapy that we start to introduce a lot a environment variables for all this stuff. (A lot in this context is two). Could we instead introduce two reserved symbols like this: config KCONFIG_ROOT_MENU string default "My own super duper root menu" config KCONFIG_SYMBOL_PREFIX string default "SAM_" the the configuration is included in the kconfig files, and not something you need to set in the environment. We already so something remotely like this for SYMBOLS where one can define: config MY_SYMBOLS option modules Then MY_SYMBOLS in used as replacement for SYMBOLS I did not implement this - but it looks sufficiently simple to warrant getting rid on the dependency on the enviromnet variables. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sam, All, On Friday 23 November 2012 Sam Ravnborg wrote: > On Thu, Nov 22, 2012 at 01:06:06AM +0100, Yann E. MORIN wrote: > > Currently, the root-menu label is hard-coded in the kconfig frontends > > executables. This means that two projects that use kconfig and want > > to display different root-menu labels can not share the same kconfig > > frontends. > > > > Instead of hard-coding the label in the frontends, handle it the same > > we handle the CONFIG_ prefix: > > - get the root-menu label from the environment if present > > - allow to set it at build time (eg. -DROOTMENU='"Root menu label"') > > - fallback to a hard-coded default > > I have note paid attention to these CONFIG_ patches - and only now > I took a short look at this set and I am not soo hapy > that we start to introduce a lot a environment variables for all this stuff. > > (A lot in this context is two). Note that we already make heavy use of environment variables in the kconfig frontends; from Documentation/kbuild/kconfig.txt: KCONFIG_ALLCONFIG KCONFIG_AUTOCONFIG KCONFIG_AUTOHEADER KCONFIG_CONFIG KCONFIG_NOSILENTUPDATE KCONFIG_OVERWRITECONFIG KCONFIG_TRISTATE They are all prefixed with KCONFIG_, which I did not do in my submission, because: - for CONFIG_, we already used a macro named CONFIG_, and I just reproduced that - for CONFIG_ROOTMENU, I just mimicked CONFIG_ and appended ROOTMENU Obviously, CONFIG_ and CONFIG_ROOTMENU should be renamed, if we eventually want to keep them: - CONFIG_ --> KCONFIG_CONFIG_ or KCONFIG_CONFIG_PREFIX ? - CONFIG_ROOTMENU --> KCONFIG_ROOTMENU Note: I missed updating the Documentation with these two new variables. > Could we instead introduce two reserved symbols like this: > > config KCONFIG_ROOT_MENU > string > default "My own super duper root menu" For the root-menu label, no need to add such a specific symbol, as we already have the 'mainmenu' directive that sets the root-menu label, eg.: mainmenu "My own super duper root menu" > config KCONFIG_SYMBOL_PREFIX > string > default "SAM_" I am a bit uneasy adding magic in the kconfig language to drive the behavior of the frontends. To me, it makes more sense to drive the frontends using environment variables. > We already so something remotely like this for SYMBOLS > where one can define: > > config MY_SYMBOLS > option modules > > Then MY_SYMBOLS in used as replacement for SYMBOLS You mean, for MODULES? There's also DEFCONFIG_LIST. > I did not implement this - but it looks sufficiently simple > to warrant getting rid on the dependency on the enviromnet variables. We already have 7 environment variables. That's just two more of them. Anyway, I'll rework the series: - fix the variables names - add documentation I'll also tackle this using config symbols instead. Michal, now you have applied the CONFIG_ patches, what should I do to rename it, so it is prefixed with KCONFIG_: - prepare a patch on your kconuild/kconfig branch, or - resubmit a complete series, that you'll apply after you trim the already applied changes? What name would you prefer to rename CONFIG_ to: - KCONFIG_CONFIG_, or - KCONFIG_CONFIG_PREFIX? Regards, Yann E. MORIN.
On Fri, Nov 23, 2012 at 10:21:44PM +0100, Yann E. MORIN wrote: > Sam, All, > > On Friday 23 November 2012 Sam Ravnborg wrote: > > On Thu, Nov 22, 2012 at 01:06:06AM +0100, Yann E. MORIN wrote: > > > Currently, the root-menu label is hard-coded in the kconfig frontends > > > executables. This means that two projects that use kconfig and want > > > to display different root-menu labels can not share the same kconfig > > > frontends. > > > > > > Instead of hard-coding the label in the frontends, handle it the same > > > we handle the CONFIG_ prefix: > > > - get the root-menu label from the environment if present > > > - allow to set it at build time (eg. -DROOTMENU='"Root menu label"') > > > - fallback to a hard-coded default > > > > I have note paid attention to these CONFIG_ patches - and only now > > I took a short look at this set and I am not soo hapy > > that we start to introduce a lot a environment variables for all this stuff. > > > > (A lot in this context is two). > > Note that we already make heavy use of environment variables in the kconfig > frontends; from Documentation/kbuild/kconfig.txt: > KCONFIG_ALLCONFIG > KCONFIG_AUTOHEADER > KCONFIG_NOSILENTUPDATE > KCONFIG_OVERWRITECONFIG Common for all of these is that they change the behaviour of the fronendts concerning their inputs etc. But none of them change the behaviour so the output become useless. Also common for these is that they are optional. If they are not specified kconfig will work as usual and the generated output will be just fine. > KCONFIG_CONFIG > KCONFIG_AUTOCONFIG > KCONFIG_TRISTATE These are used for non-default file loactions... > > Could we instead introduce two reserved symbols like this: > > > > config KCONFIG_ROOT_MENU > > string > > default "My own super duper root menu" > > For the root-menu label, no need to add such a specific symbol, as > we already have the 'mainmenu' directive that sets the root-menu > label, eg.: > mainmenu "My own super duper root menu" Had forgoten about this - why is it that we do not use this, but invent an environment variable? > > > config KCONFIG_SYMBOL_PREFIX > > string > > default "SAM_" > > I am a bit uneasy adding magic in the kconfig language to drive the > behavior of the frontends. > > To me, it makes more sense to drive the frontends using environment > variables. Using magic kconfig symbols to decide for core functionality is IMO a nice way to do so. I never liked (and still do not like) how environment variables are used to adjust the front-end behaviour. The real reason why we use environment variables is that we cannot specify options for kconfig when we invoke make. I long time ago played with the though that the kernel build should be started with a shell script named "kbuild" to give us this added flexibility. But I gave up as I back then did not have any real good reason to do so. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sam, Michal, All, Sam, see my comments in-lined below. Michal, there are a bunch of questions for you toward the end. Others: your feedback is also most welcome! ;-) On Sunday 25 November 2012 Sam Ravnborg wrote: > On Fri, Nov 23, 2012 at 10:21:44PM +0100, Yann E. MORIN wrote: > > On Friday 23 November 2012 Sam Ravnborg wrote: [--SNIP--] > > > Could we instead introduce two reserved symbols like this: > > > > > > config KCONFIG_ROOT_MENU > > > string > > > default "My own super duper root menu" > > > > For the root-menu label, no need to add such a specific symbol, as > > we already have the 'mainmenu' directive that sets the root-menu > > label, eg.: > > mainmenu "My own super duper root menu" > > Had forgoten about this - why is it that we do not use this, but invent > an environment variable? Just the sake of homogeneity: as I already introduced environment variable to change the CONFIG_ prefix, then I also added an env var for the root-menu, too. But agreed, I'll drop the root-menu patches, since we already havea run-time solution to override it. > > > config KCONFIG_SYMBOL_PREFIX > > > string > > > default "SAM_" OK, I'm tackling this, but my head is on the verge of exploding, trying to follow all those intricate calls in the kconfig parser/menu layout. /me goes and gets an aspirin. ;-) However, rather than hard-coding the symbol name, what about introducing a new 'option' keyword: config BLABLA # Name of symbol is not meaningful string default "SAM_" option prefix Currently, the only symbol (AFAIK) that is hard-coded is MODULES, which can be overloaded with 'option modules' to another symbol. I would not like to add any hard-coded symbol name. Michal, as maintainer for this, we need your input: - do you want to keep the CONFIG_ environment variable, or do you prefer the symbol trick? If you prefer the env var: - are you happy with the current naming? - if not, what name do you prefer: KCONFIG_CONFIG_ or KCONFIG_PREFIX, or anything else? Then, how do you want me to proceed: send a fix-up patch, or re-submit the previous series with the rename? If you prefer the symbol trick: - will just revert my previously applied CONFIG_ series, or should I send a fix-up series that removes it before introducing the symbol trick? - do you prefer we hard-code the feature in the symbol name, or is the 'option prefix' better suited? > I never liked (and still do not like) how environment > variables are used to adjust the front-end behaviour. > The real reason why we use environment variables is that we cannot > specify options for kconfig when we invoke make. Yes, that's also on my todo-list: add a generic option-parsing function in a common file, and have all frontends call it. It's on the todo-list. so don't hold your breadth... ;-) Regards, Yann E. MORIN.
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile index 231b475..493da53 100644 --- a/scripts/kconfig/Makefile +++ b/scripts/kconfig/Makefile @@ -11,8 +11,9 @@ else Kconfig := Kconfig endif -# We need this, in case the user has it in its environment +# We need these, in case the user has them in its environment unexport CONFIG_ +unexport CONFIG_ROOTMENU xconfig: $(obj)/qconf $< $(Kconfig) diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h index 5cfd940..93b9e69 100644 --- a/scripts/kconfig/lkc.h +++ b/scripts/kconfig/lkc.h @@ -46,6 +46,14 @@ static inline const char *CONFIG_prefix(void) #undef CONFIG_ #define CONFIG_ CONFIG_prefix() +#ifndef CONFIG_ROOTMENU +#define CONFIG_ROOTMENU "Linux Kernel Configuration" +#endif +static inline const char *CONFIG_rootmenu(void) +{ + return getenv( "CONFIG_ROOTMENU" ) ?: CONFIG_ROOTMENU; +} + #define TF_COMMAND 0x0001 #define TF_PARAM 0x0002 #define TF_OPTION 0x0004 diff --git a/scripts/kconfig/zconf.tab.c_shipped b/scripts/kconfig/zconf.tab.c_shipped index f636141..8c91e69 100644 --- a/scripts/kconfig/zconf.tab.c_shipped +++ b/scripts/kconfig/zconf.tab.c_shipped @@ -2259,7 +2259,7 @@ void conf_parse(const char *name) modules_sym = sym_lookup(NULL, 0); modules_sym->type = S_BOOLEAN; modules_sym->flags |= SYMBOL_AUTO; - rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL); + rootmenu.prompt = menu_add_prompt(P_MENU, CONFIG_rootmenu(), NULL); if (getenv("ZCONF_DEBUG")) zconfdebug = 1; diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y index 864da07..9ce6935 100644 --- a/scripts/kconfig/zconf.y +++ b/scripts/kconfig/zconf.y @@ -496,7 +496,7 @@ void conf_parse(const char *name) modules_sym = sym_lookup(NULL, 0); modules_sym->type = S_BOOLEAN; modules_sym->flags |= SYMBOL_AUTO; - rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL); + rootmenu.prompt = menu_add_prompt(P_MENU, CONFIG_rootmenu(), NULL); if (getenv("ZCONF_DEBUG")) zconfdebug = 1;
Currently, the root-menu label is hard-coded in the kconfig frontends executables. This means that two projects that use kconfig and want to display different root-menu labels can not share the same kconfig frontends. Instead of hard-coding the label in the frontends, handle it the same we handle the CONFIG_ prefix: - get the root-menu label from the environment if present - allow to set it at build time (eg. -DROOTMENU='"Root menu label"') - fallback to a hard-coded default (Note: the kconfig 'mainmenu' directive still has precedence) (refresh zconf.tab.c_shipped to match) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- scripts/kconfig/Makefile | 3 ++- scripts/kconfig/lkc.h | 8 ++++++++ scripts/kconfig/zconf.tab.c_shipped | 2 +- scripts/kconfig/zconf.y | 2 +- 4 files changed, 12 insertions(+), 3 deletions(-)