Hi there!
This series attempts to make the .config file format make more sense.
Currently menuconfig blocks look exactly like regular configs while
comment blocks look almost exactly like menu blocks.
The first patch makes menuconfig blocks look the same as menu blocks.
The second makes comment blocks look different than menu blocks.
The format for comment blocks in the second patch is a suggestion. I
realize some people will think the '###' prefix is distasteful. I'm open
to other options as well, I just couldn't think of a better option that
starts with '#', looks different from a menu and can't be confused with
a disabled config.
Ariel Marcovitch (2):
kconfig: Show menuconfigs as menus in the .config file
kconfig: Make comments look different than menus in .config
scripts/kconfig/confdata.c | 34 +++++++++++++++++++++++-----------
1 file changed, 23 insertions(+), 11 deletions(-)
base-commit: e06a61a89ccd3edda046c78f9d08aa045b8c4d32
--
2.25.1
Until now, menuconfigs were considered configs because they had non-zero
sym attribute. This meant that instead of having the nice menu comment
block in the .config output file, they were merely shown as single
configs.
For example:
```Kconfig
menu "Foo"
endmenu
menuconfig BAR
bool "Bar"
config OTHER
bool "Other"
depends on BAR
```
Will be shown as:
```.config
#
# Foo
#
# end of Foo
CONFIG_BAR=y
CONFIG_OTHER=y
```
Instead of using the sym attribute to decide whether or not to print the
menu block comment, check menu->prompt->type explicitly (after checking
that menu_is_visible(menu) which means menu->prompt is not none). The
only prompt types we actually show as menus are P_MENU and P_COMMENT. At
the end of the menu we need to show the end of block only for P_MENU
(although P_COMMENT prompts will not get to this flow because they don't
have children).
Signed-off-by: Ariel Marcovitch <[email protected]>
---
scripts/kconfig/confdata.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 42bc56ee238c..9f2c22f46ee0 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -874,16 +874,21 @@ int conf_write(const char *name)
menu = rootmenu.list;
while (menu) {
sym = menu->sym;
- if (!sym) {
- if (!menu_is_visible(menu))
- goto next;
- str = menu_get_prompt(menu);
- fprintf(out, "\n"
- "#\n"
- "# %s\n"
- "#\n", str);
- need_newline = false;
- } else if (!(sym->flags & SYMBOL_CHOICE) &&
+
+ if (menu_is_visible(menu)) {
+ enum prop_type type = menu->prompt->type;
+
+ if (type == P_MENU || type == P_COMMENT) {
+ str = menu_get_prompt(menu);
+ fprintf(out, "\n"
+ "#\n"
+ "# %s\n"
+ "#\n", str);
+ need_newline = false;
+ }
+ }
+
+ if (sym && !(sym->flags & SYMBOL_CHOICE) &&
!(sym->flags & SYMBOL_WRITTEN)) {
sym_calc_value(sym);
if (!(sym->flags & SYMBOL_WRITE))
@@ -904,7 +909,8 @@ int conf_write(const char *name)
if (menu->next)
menu = menu->next;
else while ((menu = menu->parent)) {
- if (!menu->sym && menu_is_visible(menu) &&
+ if (menu_is_visible(menu) &&
+ menu->prompt->type == P_MENU &&
menu != &rootmenu) {
str = menu_get_prompt(menu);
fprintf(out, "# end of %s\n", str);
--
2.25.1
Currently, the same code that handles menus in the write to .config
handles comments as well. That's why comments look exactly like menus in
the .config except for the 'end of menu' comments that appear only for
menus. This makes sense because sometimes comments are used as sort of
submenus. However for the other cases, it looks kinda weird because one
might attempt to look for the 'end of menu' for comments as well and be
very confused.
Make comments look different than menus. For the following:
```kconfig
menu "Stuff"
config FOO
def_bool y
comment "Some comment"
config BAR
def_bool n
endmenu
```
The .config will look like this:
```
#
# Stuff
#
CONFIG_FOO=y
### Some comment
# CONFIG_BAR is not defined
# end of Stuff
```
Signed-off-by: Ariel Marcovitch <[email protected]>
---
scripts/kconfig/confdata.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 9f2c22f46ee0..d3ec1ad67d92 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -880,10 +880,16 @@ int conf_write(const char *name)
if (type == P_MENU || type == P_COMMENT) {
str = menu_get_prompt(menu);
- fprintf(out, "\n"
- "#\n"
- "# %s\n"
- "#\n", str);
+
+ if (type == P_MENU)
+ fprintf(out, "\n"
+ "#\n"
+ "# %s\n"
+ "#\n", str);
+ else
+ fprintf(out, "\n"
+ "### %s\n", str);
+
need_newline = false;
}
}
--
2.25.1
Ariel Marcovitch <[email protected]> writes:
> The format for comment blocks in the second patch is a suggestion. I
> realize some people will think the '###' prefix is distasteful. I'm open
> to other options as well, I just couldn't think of a better option that
> starts with '#', looks different from a menu and can't be confused with
> a disabled config.
Maybe instead of decorating the comment, it makes sense to decorate
(and improve, while at it) the menu? Something along these lines:
#-
# Foo
#
CONFIG_FOO=y
# Comment.
# CONFIG_BAR is not defined
#
# Foo
#-
I also don't think a command is likely to confused with disabled option.
On 13/12/2021 13:47, Boris Kolpackov wrote:
> Ariel Marcovitch <[email protected]> writes:
>
>> The format for comment blocks in the second patch is a suggestion. I
>> realize some people will think the '###' prefix is distasteful. I'm open
>> to other options as well, I just couldn't think of a better option that
>> starts with '#', looks different from a menu and can't be confused with
>> a disabled config.
> Maybe instead of decorating the comment, it makes sense to decorate
> (and improve, while at it) the menu? Something along these lines:
>
> #-
> # Foo
> #
>
> CONFIG_FOO=y
>
> # Comment.
>
> # CONFIG_BAR is not defined
>
> #
> # Foo
> #-
>
> I also don't think a command is likely to confused with disabled option.
I mean that a comment like this - "CONFIG_FOO is not defined" will be
considered by kconfig as a config, rather than a comment. Apart from
this theoretical case which is not really likely to happen, making a
comment only one line and similar to other lines that start with '#'
really decreases the visibility of these comments.
As for the other suggestions, I think a bigger change will be even
harder for people to accept, but I will leave it to the people to decide.
Thanks for the feedback!
- Ariel Marcovitch
Ping (would really like some feedback on this)
On 13/12/2021 12:00, Ariel Marcovitch wrote:
> Hi there!
>
> This series attempts to make the .config file format make more sense.
> Currently menuconfig blocks look exactly like regular configs while
> comment blocks look almost exactly like menu blocks.
>
> The first patch makes menuconfig blocks look the same as menu blocks.
>
> The second makes comment blocks look different than menu blocks.
>
> The format for comment blocks in the second patch is a suggestion. I
> realize some people will think the '###' prefix is distasteful. I'm open
> to other options as well, I just couldn't think of a better option that
> starts with '#', looks different from a menu and can't be confused with
> a disabled config.
>
> Ariel Marcovitch (2):
> kconfig: Show menuconfigs as menus in the .config file
> kconfig: Make comments look different than menus in .config
>
> scripts/kconfig/confdata.c | 34 +++++++++++++++++++++++-----------
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
>
> base-commit: e06a61a89ccd3edda046c78f9d08aa045b8c4d32
Ping (would really like some feedback :) )
On 13/12/2021 12:00, Ariel Marcovitch wrote:
> Hi there!
>
> This series attempts to make the .config file format make more sense.
> Currently menuconfig blocks look exactly like regular configs while
> comment blocks look almost exactly like menu blocks.
>
> The first patch makes menuconfig blocks look the same as menu blocks.
>
> The second makes comment blocks look different than menu blocks.
>
> The format for comment blocks in the second patch is a suggestion. I
> realize some people will think the '###' prefix is distasteful. I'm open
> to other options as well, I just couldn't think of a better option that
> starts with '#', looks different from a menu and can't be confused with
> a disabled config.
>
> Ariel Marcovitch (2):
> kconfig: Show menuconfigs as menus in the .config file
> kconfig: Make comments look different than menus in .config
>
> scripts/kconfig/confdata.c | 34 +++++++++++++++++++++++-----------
> 1 file changed, 23 insertions(+), 11 deletions(-)
>
>
> base-commit: e06a61a89ccd3edda046c78f9d08aa045b8c4d32
On Mon, Dec 13, 2021 at 7:01 PM Ariel Marcovitch
<[email protected]> wrote:
>
> Until now, menuconfigs were considered configs because they had non-zero
> sym attribute. This meant that instead of having the nice menu comment
> block in the .config output file, they were merely shown as single
> configs.
>
> For example:
> ```Kconfig
> menu "Foo"
> endmenu
>
> menuconfig BAR
> bool "Bar"
>
> config OTHER
> bool "Other"
> depends on BAR
> ```
>
> Will be shown as:
> ```.config
> #
> # Foo
> #
> # end of Foo
I am OK with this patch.
Just a nit.
As far as I tested your sample code (without applying this patch),
I did not see the line "# end of Foo".
The line "# end of ..." is printed when the last child gets back to
its parent, but the "Foo" menu has no child menu here.
This is out of scope of this patch, but can you update the
commit log so it matches the current behavior?
(or add one config into the "Foo" menu)
>
> CONFIG_BAR=y
> CONFIG_OTHER=y
> ```
>
> Instead of using the sym attribute to decide whether or not to print the
> menu block comment, check menu->prompt->type explicitly (after checking
> that menu_is_visible(menu) which means menu->prompt is not none). The
> only prompt types we actually show as menus are P_MENU and P_COMMENT. At
> the end of the menu we need to show the end of block only for P_MENU
> (although P_COMMENT prompts will not get to this flow because they don't
> have children).
>
> Signed-off-by: Ariel Marcovitch <[email protected]>
> ---
> scripts/kconfig/confdata.c | 28 +++++++++++++++++-----------
> 1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 42bc56ee238c..9f2c22f46ee0 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -874,16 +874,21 @@ int conf_write(const char *name)
> menu = rootmenu.list;
> while (menu) {
> sym = menu->sym;
> - if (!sym) {
> - if (!menu_is_visible(menu))
> - goto next;
> - str = menu_get_prompt(menu);
> - fprintf(out, "\n"
> - "#\n"
> - "# %s\n"
> - "#\n", str);
> - need_newline = false;
> - } else if (!(sym->flags & SYMBOL_CHOICE) &&
> +
> + if (menu_is_visible(menu)) {
> + enum prop_type type = menu->prompt->type;
> +
> + if (type == P_MENU || type == P_COMMENT) {
> + str = menu_get_prompt(menu);
> + fprintf(out, "\n"
> + "#\n"
> + "# %s\n"
> + "#\n", str);
> + need_newline = false;
> + }
> + }
> +
> + if (sym && !(sym->flags & SYMBOL_CHOICE) &&
> !(sym->flags & SYMBOL_WRITTEN)) {
> sym_calc_value(sym);
> if (!(sym->flags & SYMBOL_WRITE))
> @@ -904,7 +909,8 @@ int conf_write(const char *name)
> if (menu->next)
> menu = menu->next;
> else while ((menu = menu->parent)) {
> - if (!menu->sym && menu_is_visible(menu) &&
> + if (menu_is_visible(menu) &&
> + menu->prompt->type == P_MENU &&
> menu != &rootmenu) {
> str = menu_get_prompt(menu);
> fprintf(out, "# end of %s\n", str);
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
On Mon, Dec 13, 2021 at 7:01 PM Ariel Marcovitch
<[email protected]> wrote:
>
> Currently, the same code that handles menus in the write to .config
> handles comments as well. That's why comments look exactly like menus in
> the .config except for the 'end of menu' comments that appear only for
> menus. This makes sense because sometimes comments are used as sort of
> submenus. However for the other cases, it looks kinda weird because one
> might attempt to look for the 'end of menu' for comments as well and be
> very confused.
>
> Make comments look different than menus. For the following:
> ```kconfig
> menu "Stuff"
>
> config FOO
> def_bool y
>
> comment "Some comment"
>
> config BAR
> def_bool n
>
> endmenu
> ```
>
> The .config will look like this:
> ```
> #
> # Stuff
> #
> CONFIG_FOO=y
>
> ### Some comment
> # CONFIG_BAR is not defined
> # end of Stuff
>
> ```
>
> Signed-off-by: Ariel Marcovitch <[email protected]>
> ---
> scripts/kconfig/confdata.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 9f2c22f46ee0..d3ec1ad67d92 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -880,10 +880,16 @@ int conf_write(const char *name)
>
> if (type == P_MENU || type == P_COMMENT) {
> str = menu_get_prompt(menu);
> - fprintf(out, "\n"
> - "#\n"
> - "# %s\n"
> - "#\n", str);
> +
> + if (type == P_MENU)
> + fprintf(out, "\n"
> + "#\n"
> + "# %s\n"
> + "#\n", str);
> + else
> + fprintf(out, "\n"
> + "### %s\n", str);
> +
> need_newline = false;
> }
> }
> --
> 2.25.1
>
Since "# CONFIG... is not set" looks like a comment,
I am not sure if this improves the visibility.
I will not pick up this until I find out what a really good format is.
--
Best Regards
Masahiro Yamada
Hello!
On 18/01/2022 20:20, Masahiro Yamada wrote:
> On Mon, Dec 13, 2021 at 7:01 PM Ariel Marcovitch
> <[email protected]> wrote:
>> Until now, menuconfigs were considered configs because they had non-zero
>> sym attribute. This meant that instead of having the nice menu comment
>> block in the .config output file, they were merely shown as single
>> configs.
>>
>> For example:
>> ```Kconfig
>> menu "Foo"
>> endmenu
>>
>> menuconfig BAR
>> bool "Bar"
>>
>> config OTHER
>> bool "Other"
>> depends on BAR
>> ```
>>
>> Will be shown as:
>> ```.config
>> #
>> # Foo
>> #
>> # end of Foo
>
> I am OK with this patch.
>
> Just a nit.
>
> As far as I tested your sample code (without applying this patch),
> I did not see the line "# end of Foo".
>
> The line "# end of ..." is printed when the last child gets back to
> its parent, but the "Foo" menu has no child menu here.
>
> This is out of scope of this patch, but can you update the
> commit log so it matches the current behavior?
I saw you added a patch to change that, so now the code sample here is
less of a lie :)
I learned my message of never adding code samples to commit messages
without testing these as well :)
So is it ready now to be applied on top of your change?
> (or add one config into the "Foo" menu)
>
>
>
>
>
>
>
>> CONFIG_BAR=y
>> CONFIG_OTHER=y
>> ```
>>
>> Instead of using the sym attribute to decide whether or not to print the
>> menu block comment, check menu->prompt->type explicitly (after checking
>> that menu_is_visible(menu) which means menu->prompt is not none). The
>> only prompt types we actually show as menus are P_MENU and P_COMMENT. At
>> the end of the menu we need to show the end of block only for P_MENU
>> (although P_COMMENT prompts will not get to this flow because they don't
>> have children).
>>
>> Signed-off-by: Ariel Marcovitch <[email protected]>
>> ---
>> scripts/kconfig/confdata.c | 28 +++++++++++++++++-----------
>> 1 file changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
>> index 42bc56ee238c..9f2c22f46ee0 100644
>> --- a/scripts/kconfig/confdata.c
>> +++ b/scripts/kconfig/confdata.c
>> @@ -874,16 +874,21 @@ int conf_write(const char *name)
>> menu = rootmenu.list;
>> while (menu) {
>> sym = menu->sym;
>> - if (!sym) {
>> - if (!menu_is_visible(menu))
>> - goto next;
>> - str = menu_get_prompt(menu);
>> - fprintf(out, "\n"
>> - "#\n"
>> - "# %s\n"
>> - "#\n", str);
>> - need_newline = false;
>> - } else if (!(sym->flags & SYMBOL_CHOICE) &&
>> +
>> + if (menu_is_visible(menu)) {
>> + enum prop_type type = menu->prompt->type;
>> +
>> + if (type == P_MENU || type == P_COMMENT) {
>> + str = menu_get_prompt(menu);
>> + fprintf(out, "\n"
>> + "#\n"
>> + "# %s\n"
>> + "#\n", str);
>> + need_newline = false;
>> + }
>> + }
>> +
>> + if (sym && !(sym->flags & SYMBOL_CHOICE) &&
>> !(sym->flags & SYMBOL_WRITTEN)) {
>> sym_calc_value(sym);
>> if (!(sym->flags & SYMBOL_WRITE))
>> @@ -904,7 +909,8 @@ int conf_write(const char *name)
>> if (menu->next)
>> menu = menu->next;
>> else while ((menu = menu->parent)) {
>> - if (!menu->sym && menu_is_visible(menu) &&
>> + if (menu_is_visible(menu) &&
>> + menu->prompt->type == P_MENU &&
>> menu != &rootmenu) {
>> str = menu_get_prompt(menu);
>> fprintf(out, "# end of %s\n", str);
>> --
>> 2.25.1
>>
On 18/01/2022 20:25, Masahiro Yamada wrote:
> On Mon, Dec 13, 2021 at 7:01 PM Ariel Marcovitch
> <[email protected]> wrote:
>> Currently, the same code that handles menus in the write to .config
>> handles comments as well. That's why comments look exactly like menus in
>> the .config except for the 'end of menu' comments that appear only for
>> menus. This makes sense because sometimes comments are used as sort of
>> submenus. However for the other cases, it looks kinda weird because one
>> might attempt to look for the 'end of menu' for comments as well and be
>> very confused.
>>
>> Make comments look different than menus. For the following:
>> ```kconfig
>> menu "Stuff"
>>
>> config FOO
>> def_bool y
>>
>> comment "Some comment"
>>
>> config BAR
>> def_bool n
>>
>> endmenu
>> ```
>>
>> The .config will look like this:
>> ```
>> #
>> # Stuff
>> #
>> CONFIG_FOO=y
>>
>> ### Some comment
>> # CONFIG_BAR is not defined
>> # end of Stuff
>>
>> ```
>>
>> Signed-off-by: Ariel Marcovitch <[email protected]>
>> ---
>> scripts/kconfig/confdata.c | 14 ++++++++++----
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
>> index 9f2c22f46ee0..d3ec1ad67d92 100644
>> --- a/scripts/kconfig/confdata.c
>> +++ b/scripts/kconfig/confdata.c
>> @@ -880,10 +880,16 @@ int conf_write(const char *name)
>>
>> if (type == P_MENU || type == P_COMMENT) {
>> str = menu_get_prompt(menu);
>> - fprintf(out, "\n"
>> - "#\n"
>> - "# %s\n"
>> - "#\n", str);
>> +
>> + if (type == P_MENU)
>> + fprintf(out, "\n"
>> + "#\n"
>> + "# %s\n"
>> + "#\n", str);
>> + else
>> + fprintf(out, "\n"
>> + "### %s\n", str);
>> +
>> need_newline = false;
>> }
>> }
>> --
>> 2.25.1
>>
>
> Since "# CONFIG... is not set" looks like a comment,
> I am not sure if this improves the visibility.
I agree that adding another '#' signs to the real comments doesn't solve
the real
problem here, being that kconfig uses comments to save actual information
I guess this is for being able to check for a config in shell script
with [[ -n $CONFIG_FOO ]]?
Although if that's the case, leaving the config empty has the same
effect, no? And then
we can add a comment to the end of the definition stating that the
config is unset.
Something like this:
CONFIG_FOO=y
CONFIG_BAR= # is not set
It may break scripts doing something like this:
: ${CONFIG_FOO=?Config FOO must be defined}
But they can be changed to use ':?' instead (which checks for non-zero
length string
rather than whether the variable is defined or not)
Actually, now that I think of it, it might even be an improvement for
scripts to be able to tell whether a config isn't defined or whether it
has an 'n' value
Anyway, I'm absolutely fine with delaying this patch until we find a
solution
>
> I will not pick up this until I find out what a really good format is.
Thanks!
On Sat, Feb 19, 2022 at 3:39 AM Ariel Marcovitch
<[email protected]> wrote:
>
> Hello!
>
> On 18/01/2022 20:20, Masahiro Yamada wrote:
> > On Mon, Dec 13, 2021 at 7:01 PM Ariel Marcovitch
> > <[email protected]> wrote:
> >> Until now, menuconfigs were considered configs because they had non-zero
> >> sym attribute. This meant that instead of having the nice menu comment
> >> block in the .config output file, they were merely shown as single
> >> configs.
> >>
> >> For example:
> >> ```Kconfig
> >> menu "Foo"
> >> endmenu
> >>
> >> menuconfig BAR
> >> bool "Bar"
> >>
> >> config OTHER
> >> bool "Other"
> >> depends on BAR
> >> ```
> >>
> >> Will be shown as:
> >> ```.config
> >> #
> >> # Foo
> >> #
> >> # end of Foo
> >
> > I am OK with this patch.
> >
> > Just a nit.
> >
> > As far as I tested your sample code (without applying this patch),
> > I did not see the line "# end of Foo".
> >
> > The line "# end of ..." is printed when the last child gets back to
> > its parent, but the "Foo" menu has no child menu here.
> >
> > This is out of scope of this patch, but can you update the
> > commit log so it matches the current behavior?
>
> I saw you added a patch to change that, so now the code sample here is
> less of a lie :)
>
> I learned my message of never adding code samples to commit messages
> without testing these as well :)
>
> So is it ready now to be applied on top of your change?
Yes, v2 please.
> > (or add one config into the "Foo" menu)
> >
> >
> >
> >
> >
> >
> >
> >> CONFIG_BAR=y
> >> CONFIG_OTHER=y
> >> ```
> >>
> >> Instead of using the sym attribute to decide whether or not to print the
> >> menu block comment, check menu->prompt->type explicitly (after checking
> >> that menu_is_visible(menu) which means menu->prompt is not none). The
> >> only prompt types we actually show as menus are P_MENU and P_COMMENT. At
> >> the end of the menu we need to show the end of block only for P_MENU
> >> (although P_COMMENT prompts will not get to this flow because they don't
> >> have children).
> >>
> >> Signed-off-by: Ariel Marcovitch <[email protected]>
> >> ---
> >> scripts/kconfig/confdata.c | 28 +++++++++++++++++-----------
> >> 1 file changed, 17 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> >> index 42bc56ee238c..9f2c22f46ee0 100644
> >> --- a/scripts/kconfig/confdata.c
> >> +++ b/scripts/kconfig/confdata.c
> >> @@ -874,16 +874,21 @@ int conf_write(const char *name)
> >> menu = rootmenu.list;
> >> while (menu) {
> >> sym = menu->sym;
> >> - if (!sym) {
> >> - if (!menu_is_visible(menu))
> >> - goto next;
> >> - str = menu_get_prompt(menu);
> >> - fprintf(out, "\n"
> >> - "#\n"
> >> - "# %s\n"
> >> - "#\n", str);
> >> - need_newline = false;
> >> - } else if (!(sym->flags & SYMBOL_CHOICE) &&
> >> +
> >> + if (menu_is_visible(menu)) {
> >> + enum prop_type type = menu->prompt->type;
> >> +
> >> + if (type == P_MENU || type == P_COMMENT) {
> >> + str = menu_get_prompt(menu);
> >> + fprintf(out, "\n"
> >> + "#\n"
> >> + "# %s\n"
> >> + "#\n", str);
> >> + need_newline = false;
> >> + }
> >> + }
> >> +
> >> + if (sym && !(sym->flags & SYMBOL_CHOICE) &&
> >> !(sym->flags & SYMBOL_WRITTEN)) {
> >> sym_calc_value(sym);
> >> if (!(sym->flags & SYMBOL_WRITE))
> >> @@ -904,7 +909,8 @@ int conf_write(const char *name)
> >> if (menu->next)
> >> menu = menu->next;
> >> else while ((menu = menu->parent)) {
> >> - if (!menu->sym && menu_is_visible(menu) &&
> >> + if (menu_is_visible(menu) &&
> >> + menu->prompt->type == P_MENU &&
> >> menu != &rootmenu) {
> >> str = menu_get_prompt(menu);
> >> fprintf(out, "# end of %s\n", str);
> >> --
> >> 2.25.1
> >>
--
Best Regards
Masahiro Yamada
On Sat, Feb 19, 2022 at 3:55 AM Ariel Marcovitch
<[email protected]> wrote:
>
> On 18/01/2022 20:25, Masahiro Yamada wrote:
> > On Mon, Dec 13, 2021 at 7:01 PM Ariel Marcovitch
> > <[email protected]> wrote:
> >> Currently, the same code that handles menus in the write to .config
> >> handles comments as well. That's why comments look exactly like menus in
> >> the .config except for the 'end of menu' comments that appear only for
> >> menus. This makes sense because sometimes comments are used as sort of
> >> submenus. However for the other cases, it looks kinda weird because one
> >> might attempt to look for the 'end of menu' for comments as well and be
> >> very confused.
> >>
> >> Make comments look different than menus. For the following:
> >> ```kconfig
> >> menu "Stuff"
> >>
> >> config FOO
> >> def_bool y
> >>
> >> comment "Some comment"
> >>
> >> config BAR
> >> def_bool n
> >>
> >> endmenu
> >> ```
> >>
> >> The .config will look like this:
> >> ```
> >> #
> >> # Stuff
> >> #
> >> CONFIG_FOO=y
> >>
> >> ### Some comment
> >> # CONFIG_BAR is not defined
> >> # end of Stuff
> >>
> >> ```
> >>
> >> Signed-off-by: Ariel Marcovitch <[email protected]>
> >> ---
> >> scripts/kconfig/confdata.c | 14 ++++++++++----
> >> 1 file changed, 10 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> >> index 9f2c22f46ee0..d3ec1ad67d92 100644
> >> --- a/scripts/kconfig/confdata.c
> >> +++ b/scripts/kconfig/confdata.c
> >> @@ -880,10 +880,16 @@ int conf_write(const char *name)
> >>
> >> if (type == P_MENU || type == P_COMMENT) {
> >> str = menu_get_prompt(menu);
> >> - fprintf(out, "\n"
> >> - "#\n"
> >> - "# %s\n"
> >> - "#\n", str);
> >> +
> >> + if (type == P_MENU)
> >> + fprintf(out, "\n"
> >> + "#\n"
> >> + "# %s\n"
> >> + "#\n", str);
> >> + else
> >> + fprintf(out, "\n"
> >> + "### %s\n", str);
> >> +
> >> need_newline = false;
> >> }
> >> }
> >> --
> >> 2.25.1
> >>
> >
> > Since "# CONFIG... is not set" looks like a comment,
> > I am not sure if this improves the visibility.
>
> I agree that adding another '#' signs to the real comments doesn't solve
> the real
> problem here, being that kconfig uses comments to save actual information
>
> I guess this is for being able to check for a config in shell script
> with [[ -n $CONFIG_FOO ]]?
Maybe.
Also "ifdef CONFIG_FOO" in Makefile.
In the old days, the .config was directly included.
These days, the .config is used for the purpose of
saving the configuration, and include/config/auto.conf
>
> Although if that's the case, leaving the config empty has the same
> effect, no? And then
> we can add a comment to the end of the definition stating that the
> config is unset.
> Something like this:
>
> CONFIG_FOO=y
> CONFIG_BAR= # is not set
The most natural expression is:
CONFIG_BAR=n
--
Best Regards
Masahiro Yamada