| Age | Commit message (Collapse) | Author |
|---|
|
menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard errors.
While I was here, I moved the checks to slim down menu_finalize().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Choice members must have a prompt; hence make it an error.
While I was here, I moved the check to the parser to slim down
_menu_finalize().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This flag is set to symbols that are not intended to be written
to the .config file.
Since commit b75b0a819af9 ("kconfig: change defconfig_list option to
environment variable"), SYMBOL_NO_WRITE is only set to choices.
Therefore, (sym->flags & SYMBOL_NO_WRITE) is equivalent to
sym_is_choice(sym). This flag is no longer necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.
In the following example, both A and B can be disabled simultaneously:
choice
prompt "choose A, B, or nothing"
optional
config A
bool "A"
config B
bool "B"
endchoice
You can achieve the equivalent outcome by other means.
A common solution is to add another option to guard the choice block.
In the following example, you can set ENABLE_A_B_CHOICE=n to disable
the entire choice block:
choice
prompt "choose A or B"
depends on ENABLE_A_B_CHOICE
config A
bool "A"
config B
bool "B"
endchoice
Another approach is to insert one more entry:
choice
prompt "choose A, B, or disable both"
config A
bool "A"
config B
bool "B"
config DISABLE_A_AND_B
bool "choose this to disable both A and B"
endchoice
Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE,
LTO_NONE, etc.
The 'optional' property is even more unnecessary for a tristate choice.
Without the 'optional' property, you can disable A and B; you can set
'm' in the choice prompt, and disable A and B individually:
choice
prompt "choose one built-in or make them modular"
config A
tristate "A"
config B
tristate "B"
endchoice
In conclusion, the 'optional' property was unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
|
All symbols except choices have a name.
Previously, choices were allowed to have a name, but commit c83f020973bc
("kconfig: remove named choice support") eliminated that possibility.
Now, it is easy to distinguish choices from normal symbols; if the name
is NULL, it is a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
|
|
Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
The boolean 'choice' is used to list exclusively selected config
options.
You must not add a dependency between choice members, because such a
dependency would create an invisible entry.
In the following test case, it is impossible to choose 'C'.
[Test Case 1]
choice
prompt "Choose one, but how to choose C?"
config A
bool "A"
config B
bool "B"
config C
bool "C"
depends on A
endchoice
Hence, Kconfig shows the following error message:
Kconfig:1:error: recursive dependency detected!
Kconfig:1: choice <choice> contains symbol C
Kconfig:10: symbol C is part of choice A
Kconfig:4: symbol A is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
However, Kconfig does not report anything for the following similar code:
[Test Case 2]
choice
prompt "Choose one, but how to choose B?"
config A
bool "A"
config B
bool "B"
depends on A
config C
bool "C"
endchoice
This is because menu_finalize() reparents the menu tree when an entry
depends on the preceding one.
With reparenting, the menu tree:
choice
|- A
|- B
\- C
... will be transformed into the following structure:
choice
|- A
| \- B
\- C
Consequently, Kconfig considers only 'A' and 'C' as choice members.
This behavior is awkward. The second test case should be an error too.
This commit stops reparenting inside a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This can be checked on-the-fly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Commit 5a1aa8a1aff6 ("kconfig: add named choice group") did not provide
enough explanation regarding its benefits. A use case was found in
another project [1] sometime later, this feature has never been used in
the kernel.
[1]: https://lore.kernel.org/all/201012150034.01356.yann.morin.1998@anciens.enib.fr/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
|
|
Use helper macros in hashtable.h for generic hashtable implementation.
We can git rid of the hash head index of for_all_symbols().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
for_all_symbols() iterates in the symbol hash table. The order of
iteration depends on the hash table implementation.
If you use it for printing errors, they are shown in random order.
For example, the order of following test input and the corresponding
error do not match:
- scripts/kconfig/tests/err_recursive_dep/Kconfig
- scripts/kconfig/tests/err_recursive_dep/expected_stderr
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Currently, cur_filename is updated at the first token of each statement.
However, this seems unnecessary based on my understanding; the parser
can use the same variable as the lexer tracks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
struct menu is linked to struct file for diagnostic purposes.
It is always used to retrieve the file name through menu->file->name.
Associate struct menu with the file name directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Now zconf_curname() and zconf_lineno() are so simple that they just
return cur_filename, cur_lineno, respectively.
Remove these functions, and then use cur_filename and cur_lineno
directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
These are needed only for the parse stage. Move the prototypes into
a separate header to make sure they are not used after that.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
This allows preprocess.c to free up all of its resources when the parse
stage is finished. It also ensures conf_write_autoconf_cmd() produces
consistent results even if called multiple times for any reason.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Currently, include/config/autoconf.cmd saves included Kconfig files in
reverse order. While this is not a big deal, it is inconsistent with
other *.cmd files generated by fixdep.
Output the included Kconfig files in the included order.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
sym_find("n") is equivalent to &symbol_no.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
yyerror() reports the line number of the next line.
This +1 adjustment was introduced more than 20 years ago [1]. At that
time, the line number was decremented then incremented back and forth.
The line number management was refactored in a more maintainable way.
Such compensation is no longer needed.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=d4f8a4530eb07a1385fd17b0e62a7dce97486f49
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Compile menu.c as an independent compilation unit.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
sym_change_count has no good reason to be 'int' type.
sym_set_change_count() compares the old and new values after casting
both of them to (bool). I do not see any practical diffrence between
sym_set_change_count(1) and sym_add_change_count(1).
Use the boolean flag, conf_changed.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Now "modules" is the only member of the "option" property.
Remove "option", and move "modules" to the top level property.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Now that the only user, CONFIG_EMBEDDED has stopped using this option,
remove it entirely.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
"defconfig_list" is a weird option that defines a static symbol that
declares the list of base config files in case the .config does not
exist yet.
This is quite different from other normal symbols; we just abused the
"string" type and the "default" properties to list out the input files.
They must be fixed values since these are searched for and loaded in
the parse stage.
It is an ugly hack, and should not exist in the first place. Providing
this feature as an environment variable is a saner approach.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
The code block surrounded by 'if' ... 'endif' is reduced into if_stmt,
which is accepted in the 'choice' context. Therefore, you can write any
statements within a choice block by wrapping 'if y' ... 'end'.
For example, you can create a menu inside a choice, like follows:
---------------->8----------------
choice
prompt "choice"
config A
bool "A"
config B
bool "B"
if y
menu "strange menu"
config C
bool "C"
endmenu
endif
endchoice
---------------->8----------------
I want to change such a weird structure into a syntax error.
In fact, the USB gadget Kconfig had used nested 'choice' for no good
reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for
legacy gadget drivers") killed it.
I think the 'source' inside 'choice' is on the fence. It is at least
gramatically sensible as long as the included file contains only
bool/tristate configs. However, it makes the code unreadable, and people
tend to forget the fact that the file is included from the choice
block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to
legacy/Kconfig") got rid of the only usecase.
Going forward, you can only use 'config', 'comment', and 'if' inside
'choice'. This also recursively applies to 'if' blocks inside 'choice'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
struct property can reference to the symbol that it is associated with
by prop->menu->sym.
Fix up the one usage of prop->sym, and remove sym from struct property.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Now that 'prompt' is only reduced from T_WORD_QUOTE without any action,
use T_WORD_QUOTE directly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
Commit 8636a1f9677d ("treewide: surround Kconfig file paths with double
quotes") killed use-cases to reduce an unquoted string into the 'prompt'
symbol.
Kconfig still allows to use an unquoted string in the context of menu,
source, or prompt.
So, you can omit quoting if the prompt is a single word:
bool foo
..., but I do not think this is so useful.
Let's require quoting:
bool "foo"
All the Kconfig files in the kernel are written in this way.
Remove the T_WORD from the right-hand side of the symbol 'prompt'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
|
|
util.c exists both in scripts/kconfig/ and scripts/kconfig/lxdialog.
Prior to commit 54b8ae66ae1a ("kbuild: change *FLAGS_<basetarget>.o
to take the path relative to $(obj)"), Kbuild could not pass different
flags to source files with the same basename. Now that this issue
was solved, you can split util.c out of parser.y and compile them
independently of each other.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Use a more logical name.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
