There is no grammatical ambiguity by using T_WORD for variables.
The parser can distinguish variables from symbols from the context.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the lexer returns T_ASSIGN for all of =, :=, and +=
associating yylval with the flavor.
I want to make the generated lexer as simple as possible. So, the
lexer should convert keywords to tokens without thinking about the
meaning.
= -> T_EQUAL
:= -> T_COLON_EQUAL
+= -> T_PLUS_EQUAL
Unfortunately, Kconfig uses = instead of == for the equal operator.
So, the same token T_EQUAL is used for assignment and comparison.
The parser can still distinguish them from the context.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
For the keywords "modules", "defconfig_list", and "allnoconfig_y",
the lexer should pass specific tokens instead of generic T_WORD.
This simplifies both the lexer and the parser.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit removes kconf_id::stype to prepare for the entire
removal of kconf_id.c
To simplify the lexer, I want keywords straight-mapped to tokens.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, "visible" and "depends on", if defined in a menu entry,
must appear in that order.
The real example is in drivers/media/tuners/Kconfig:
menu "Customize TV tuners"
visible if <expr1>
depends on <expr2>
... is fine, but you cannot change the property order like this:
menu "Customize TV tuners"
depends on <expr2>
visible if <expr1>
Kconfig does not require a specific order of properties. In this case,
menu_add_visibility(() and menu_add_dep() are orthogonal.
Loosen this unreasonable restriction.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The code block surrounded by "menu" ... "endmenu" is stmt_list.
Remove the redundant menu_block symbol entirely.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The code block surrounded by "if" ... "endif" is stmt_list.
Remove the redundant if_block symbol entirely.
Remove "stmt_list: stmt_list end" rule as well since it would
obviously cause conflicts.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit decreases 6 shift/reduce conflicts, and finally achieves
conflict-free parser.
Since Kconfig has no terminator for a config block, detecting the end
of config_stmt is not easy.
For example, there are two ways for handling the error in the following
code:
1 config FOO
2 =
[A] Print "unknown option" error, assuming the line 2 is a part of
config_option_list
[B] Print "invalid statement", assuming the line 1 is reduced into
a config_stmt by itself
Bison actually chooses [A] because it performs the shift rather than
the reduction where both are possible.
However, there is no reason to choose one over the other.
Let's remove the option_error, and let it fall back to [B].
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit decreases 15 shift/reduce conflicts.
The location of this error recovery is ambiguous.
For example, there are two ways to interpret the following code:
1 config FOO
2 bool "foo"
[A] Both lines are reduced together into a config_stmt.
[B] The only line 1 is reduced into a config_stmt, and the line 2
matches to "option_name error T_EOL"
Of course, we expect [A], but [B] could be grammatically possible.
Kconfig has no terminator for a config block. So, we cannot detect its
end until we see a non-property keyword. People often insert a blank
line between two config blocks, but it is just a coding convention.
Blank lines are actually allowed anywhere in Kconfig files.
The real error is when a property keyword appears right after "endif",
"endchoice", "endmenu", "source", "comment", or variable assignment.
Instead of fixing the grammatical ambiguity, I chose to simply remove
this error recovery.
The difference is
unexpected option "bool"
... is turned into a more generic message:
invalid statement
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It would be nice to warn if a new line is missing at end of file.
We could do this by checkpatch.pl for arbitrary files, but new line
is rather essential as a statement terminator in Kconfig.
The warning message looks like this:
kernel/Kconfig.preempt:60:warning: no new line at end of file
Currently, kernel/Kconfig.preempt is the only file with no new line
at end of file. Fix it.
I know there are some false negative cases. For example, no warning
is displayed when the last line contains some whitespaces/comments,
but no new line. Yet, this commit works well for most cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
A new file should always start in the INITIAL state.
When the lexer bumps into EOF, the lexer must get back to the INITIAL
state anyway. Remove the redundant <<EOF>> pattern in the PARAM state.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit decreases 8 shift/reduce conflicts.
A certain amount of grammatical ambiguity comes from how to reduce
excessive T_EOL tokens.
Let's take a look at the example code below:
1 config A
2 bool "a"
3
4 depends on B
5
6 config B
7 def_bool y
The line 3 is melt into "config_option_list", but the line 5 can be
either a part of "config_option_list" or "common_stmt" by itself.
Currently, the lexer converts '\n' to T_EOL verbatim. In Kconfig,
a new line works as a statement terminator, but new lines in empty
lines are not critical since empty lines (or lines that contain only
whitespaces/comments) are just no-op.
If the lexer simply discards no-op lines, the parser will not be
bothered by excessive T_EOL tokens.
Of course, this means we are shifting the complexity from the parser
to the lexer, but it is much easier than tackling on shift/reduce
conflicts.
I introduced the second stage lexer to tweak the behavior.
Discard T_EOL if the previous token is T_EOL or T_HELPTEXT.
Two T_EOL tokens in a row is meaningless. T_HELPTEXT is a special
token that is reduced without T_EOL.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Here, similar matching patters are duplicated in order to look ahead
the '\n' character. If the next character is '\n', the lexer returns
T_WORD_QUOTE because it must be prepared to return T_EOL at the next
match.
Use unput('\n') trick to reduce the code duplication.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
All line-oriented statements should be reduced when seeing a T_EOL
token. I guess missing T_EOL for the "visible" statement is just a
mistake. This commit decreases one shift/reduce conflict.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
An unterminated string literal followed by new line is passed to the
parser (with "multi-line strings not supported" warning shown), then
handled properly there.
On the other hand, an unterminated string literal at end of file is
never passed to the parser, then results in memory leak.
[Test Code]
----------(Kconfig begin)----------
source "Kconfig.inc"
config A
bool "a"
-----------(Kconfig end)-----------
--------(Kconfig.inc begin)--------
config B
bool "b\No new line at end of file
---------(Kconfig.inc end)---------
[Summary from Valgrind]
Before the fix:
LEAK SUMMARY:
definitely lost: 16 bytes in 1 blocks
...
After the fix:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
...
Eliminate the memory leak path by handling this case. Of course, such
a Kconfig file is wrong already, so I will add an error message later.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, warn_ignore_character() displays invalid file name and
line number.
The lexer should use current_file->name and yylineno, while the parser
should use zconf_curname() and zconf_lineno().
This difference comes from that the lexer is always going ahead
of the parser. The parser needs to look ahead one token to make a
shift/reduce decision, so the lexer is requested to scan more text
from the input file.
This commit fixes the warning message from warn_ignored_character().
[Test Code]
----(Kconfig begin)----
/
-----(Kconfig end)-----
[Output]
Before the fix:
<none>:0:warning: ignoring unsupported character '/'
After the fix:
Kconfig:1:warning: ignoring unsupported character '/'
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The only possibility of k_invalid being returned was when
expr_parse_sting() parsed S_OTHER type symbol. This actually never
happened, and this is even clearer since S_OTHER has gone.
Clean up unreachable code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The S_OTHER type could be set only when conf_read_simple() is reading
include/config/auto.conf file.
For example, CONFIG_FOO=y exists in include/config/auto.conf but it is
missing from the currently parsed Kconfig files, sym_lookup() allocates
a new symbol, and sets its type to S_OTHER.
Strangely, it will be set to S_STRING by conf_set_sym_val() a few lines
below while it is obviously bool or tristate type. On the other hand,
when CONFIG_BAR="bar" is being dropped from include/config/auto.conf,
its type remains S_OTHER. Because for_all_symbols() omits S_OTHER
symbols, conf_touch_deps() misses to touch include/config/bar.h
This behavior has been a pretty mystery for me, and digging the git
histroy did not help. At least, touching depfiles is broken for string
type symbols.
I removed S_OTHER entirely, and reimplemented it more simply.
If CONFIG_FOO was visible in the previous syncconfig, but is missing
now, what we want to do is quite simple; just call conf_touch_dep()
to touch include/config/foo.h instead of allocating a new symbol data.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
conf_touch_deps() iterates over symbols, touching corresponding
include/config/*.h files as needed.
Split the part that touches a single file into a new helper so it can
be reused.
The new helper, conf_touch_dep(), takes a symbol name as a parameter,
and touches the corresponding include/config/*.h file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
According to commit 2e3646e51b ("kconfig: integrate split config
into silentoldconfig"), this function was named after split-include
tool, which used to exist in old versions of Linux.
Setting aside the historical reason, rename it into a more intuitive
name. This function touches timestamp files under include/config/
in order to interact with the fixdep tool.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The two 'goto setsym' statements are reachable only when sym == NULL.
The code below the 'setsym:' label does nothing when sym == NULL
since there is just one if-block guarded by 'if (sym && ...)'.
Hence, 'goto setsym' can be replaced with 'continue'.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
In today's merge_config.sh the order of the config fragment files dictates
the output of a config option. With this approach we will get different
.config files depending on the order of the config fragment files.
So doing something like:
$ ./merge/kconfig/merge_config.sh selftest.config drm.config
Where selftest.config defines DRM=y and drm.config defines DRM=m, the
result will be "DRM=m".
Rework to add a switch to get builtin '=y' precedence over modules '=m',
this will result in "DRM=y". If we do something like this:
$ ./merge/kconfig/merge_config.sh -y selftest.config drm.config
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The current SED_CONFIG_EXP could match to comment lines in config
fragment files, especially when CONFIG_PREFIX_ is empty. For example,
Buildroot uses empty prefixing; starting symbols with BR2_ is just
convention.
Make the sed expression more robust against false positives from
comment lines. The new sed expression matches to only valid patterns.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
with CONFIG_ environment variable.
merge_config.sh uses CONFIG_ which is used in kernel and other projects.
There are some projects which use kconfig with different prefixes (e.g.
buildroot: BR2_ prefix). CONFIG_ variable is already used for this
purpose in kconfig binary (scripts/kconfig/lkc.h), let's use the same
rule for in merge_config.sh.
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As commit 911a91c39c ("kconfig: rename silentoldconfig to
syncconfig") announced, it is time for the removal.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
As commit 312ee68752 ("kconfig: announce removal of oldnoconfig if
used") announced, it is time for the removal.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Meelis Roos reported a {menu,n}config regression:
"I have libncurses devel package installed in the default system
location (as do 99%+ on actual developers probably) and in this
case, pkg-config is useless. pkg-config is needed only when
libraries and headers are installed in non-default locations but
it is bad to require installation of pkg-config on all the machines
where make menuconfig would be possibly run."
For {menu,n}config, do not use pkg-config if it is not installed.
For {g,x}config, keep checking pkg-config since we really rely on it
for finding the installation paths of the required packages.
Fixes: 4ab3b80159 ("kconfig: check for pkg-config on make {menu,n,g,x}config")
Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Meelis Roos <mroos@linux.ee>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
The self assignment was probably introduced by an automated code
refactoring in
commit 694c49a7c0 ("kconfig: drop localization support").
The issue was identified by a self-assign warning when running
make menuconfig with clang.
Fixes: 694c49a7c0 ("kconfig: drop localization support")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The top-level Makefile invokes "make syncconfig" when necessary.
Then, Kconfig displays the following message when .config is updated.
#
# configuration written to .config
#
It is distracting because "make syncconfig" happens during the build
stage, and does nothing important in most cases.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit improves the messages of the recursive dependency.
Currently, sym->dir_dep.expr is not checked. Hence, any dependency
in property visibility is regarded as the dependency of the symbol.
[Test Code 1]
config A
bool "a"
depends on B
config B
bool "b"
depends on A
[Test Code 2]
config A
bool "a" if B
config B
bool "b"
depends on A
For both cases above, the same message is displayed:
symbol B depends on A
symbol A depends on B
This commit changes the message for the latter, like this:
symbol B depends on A
symbol A prompt is visible depending on B
Also, 'select' and 'imply' are distinguished.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Currently, Kconfig does not complain about the recursive dependency
where 'imply' keywords are involved.
[Test Code]
config A
bool "a"
config B
bool "b"
imply A
depends on A
In the code above, Kconfig cannot calculate the symbol values correctly
due to the circular dependency. For example, allyesconfig followed by
syncconfig results in an odd behavior because CONFIG_B becomes visible
in syncconfig.
$ make allyesconfig
scripts/kconfig/conf --allyesconfig Kconfig
#
# configuration written to .config
#
$ cat .config
#
# Automatically generated file; DO NOT EDIT.
# Main menu
#
CONFIG_A=y
$ make syncconfig
scripts/kconfig/conf --syncconfig Kconfig
*
* Restart config...
*
*
* Main menu
*
a (A) [Y/n/?] y
b (B) [N/y/?] (NEW)
To detect this correctly, sym_check_expr_deps() should recurse to
not only sym->rev_dep.expr but also sym->implied.expr .
At this moment, sym_check_print_recursive() cannot distinguish
'select' and 'imply' since it does not know the precise context
where the recursive dependency has been hit. This will be solved
by the next commit.
In fact, even the document and the unit-test are confused. Using
'imply' does not solve recursive dependency since 'imply' addresses
the unmet direct dependency, which 'select' could cause.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Originally, recursive dependency was a fatal error for Kconfig
because Kconfig cannot compute symbol values in such a situation.
Commit d595cea624 ("kconfig: print more info when we see a recursive
dependency") changed it to a warning, which I guess was not intentional.
Get it back to an error again.
Also, rename the unit test directory "warn_recursive_dep" to
"err_recursive_dep" so that it matches to the behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dirk Gouders <dirk@gouders.net>
Add build-only targets for build_menuconfig, build_nconfig,
build_xconfig, and build_gconfig.
(targets must end in "config" to qualify in top-level Makefile)
This allows these target to be built without execution (e.g., to
look for errors or warnings) and/or to be built and checked by sparse.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
- show clearer error messages where pkg-config is needed, but not
installed
- rename SYMBOL_AUTO to SYMBOL_NO_WRITE to reflect its semantics
- create all necessary directories by Kconfig tool itself instead
of Makefile
- update the .config unconditionally when syncconfig is invoked
- use 'include' directive instead of '-include' where
include/config/{auto,tristate}.conf is mandatory
- do not try to update the .config when running install targets
- add .DELETE_ON_ERROR to delete partially updated files
- misc cleanups and fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJbdFbBAAoJED2LAQed4NsGJbQP/icdG5Cj8YVuIlqBEe50KkbT
V0jJdCyxSSUXiuTaGlFJ4RFlcbH9+4JcMdGIHqRrrtW0UpqXNcHgIOjbCaq4zLCw
oRtva0/VC3KVlNDZR702t58t8os3qS03XuuRd1bBao19Mje7YOtHGrBfaEmZ3TIV
jn9TX3K8PxPE8NLRuY5P3OT4fEeeUwXbleo5RuReQR8mWY3p6Gf8YjJ/mxDnoSbF
gnot+ahWKdvJBjAbbTgoFePM7zOp4YA6Z1Nw0OerXKbchLG2D/wyDNbS2AnME3TR
RSFuEZL3LqkZlVN1q7oQ0kzVuafghcUSx5LiRovejw7ZRemU30ixqSTZ6w6aL3X8
nvm+arCGPS85v6RiPEnDMI9iXaqA0+yhwdKi3OLhoOEz+Y8G74JkOZErIoVpE2Ok
wrSrmLzLzx6kcOaL50hhWQ5Jm3SGclFO1+uEcMP2vSRrrUJlkrBRvpLm+BInFVYS
HnifGBSD73+UIrVmAcEM30YXUX4kFDoLWUd659nop270vr1JZr2/ie+WODH/fsfn
aSDQq7AUbwybYHcSnzrv/eiZ5xiDBXcfRsvAcjpwzrUzpj6mM95XwBFOk7O/4a5w
SuXiMSPbf/zemKhVp2wk6/nxS8SI07qEpXYMRcf3JL/kcT0KDg2/sPou//beYC56
/s3cTXUlMrG7KTTfr0jz
=/Dow
-----END PGP SIGNATURE-----
Merge tag 'kconfig-v4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kconfig updates from Masahiro Yamada:
- show clearer error messages where pkg-config is needed, but not
installed
- rename SYMBOL_AUTO to SYMBOL_NO_WRITE to reflect its semantics
- create all necessary directories by Kconfig tool itself instead of
Makefile
- update the .config unconditionally when syncconfig is invoked
- use 'include' directive instead of '-include' where
include/config/{auto,tristate}.conf is mandatory
- do not try to update the .config when running install targets
- add .DELETE_ON_ERROR to delete partially updated files
- misc cleanups and fixes
* tag 'kconfig-v4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kconfig: remove P_ENV property type
kconfig: remove unused sym_get_env_prop() function
kconfig: fix the rule of mainmenu_stmt symbol
init/Kconfig: Use short unix-style option instead of --longname
Kbuild: Makefile.modbuiltin: include auto.conf and tristate.conf mandatory
kbuild: remove auto.conf from prerequisite of phony targets
kbuild: do not update config for 'make kernelrelease'
kbuild: do not update config when running install targets
kbuild: add .DELETE_ON_ERROR special target
kbuild: use 'include' directive to load auto.conf from top Makefile
kconfig: allow all config targets to write auto.conf if missing
kconfig: make syncconfig update .config regardless of sym_change_count
kconfig: create directories needed for syncconfig by itself
kconfig: remove unneeded directory generation from local*config
kconfig: split out useful helpers in confdata.c
kconfig: rename file_write_dep and move it to confdata.c
kconfig: fix typos in description of "choice" in kconfig-language.txt
kconfig: handle format string before calling conf_message_callback()
kconfig: rename SYMBOL_AUTO to SYMBOL_NO_WRITE
kconfig: check for pkg-config on make {menu,n,g,x}config
This property is not set by anyone since commit 104daea149 ("kconfig:
reference environment variables directly and remove 'option env='").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
This function is unused since commit 104daea149 ("kconfig: reference
environment variables directly and remove 'option env='").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
The rule of mainmenu_stmt does not have debug print of zconf_lineno(),
but if it had, it would print a wrong line number for the same reason
as commit b2d00d7c61 ("kconfig: fix line numbers for if-entries in
menu tree").
The mainmenu_stmt does not need to eat following empty lines because
they are reduced to common_stmt.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, only syncconfig creates or updates include/config/auto.conf
and some other files. Other config targets create or update only the
.config file.
When you configure and build the kernel from a pristine source tree,
any config target is followed by syncconfig in the build stage since
include/config/auto.conf is missing.
We are moving compiler tests from Makefile to Kconfig. It means that
parsing Kconfig files will be more costly since Kconfig invokes the
compiler commands internally. Thus, we want to avoid invoking Kconfig
twice (one for *config to create the .config, and one for syncconfig
to synchronize the auto.conf). If auto.conf does not exist, we can
generate all configuration files in the first configuration stage,
which will save the syncconfig in the build stage.
Please note this should be done only when auto.conf is missing. If
*config blindly did this, time stamp files under include/config/ would
be unnecessarily touched, triggering unneeded rebuild of objects.
I assume a scenario like this:
1. You have a source tree that has already been built
with CONFIG_FOO disabled
2. Run "make menuconfig" to enable CONFIG_FOO
3. CONFIG_FOO turns out to be unnecessary.
Run "make menuconfig" again to disable CONFIG_FOO
4. Run "make"
In this case, include/config/foo.h should not be touched since there
is no change in CONFIG_FOO. The sync process should be delayed until
the user really attempts to build the kernel.
This commit has another motivation; I want to suppress the 'No such
file or directory' warning from the 'include' directive.
The top-level Makefile includes auto.conf with '-include' directive,
like this:
ifeq ($(dot-config),1)
-include include/config/auto.conf
endif
This looks strange because auto.conf is mandatory when dot-config is 1.
I guess only the reason of using '-include' is to suppress the warning
'include/config/auto.conf: No such file or directory' when building
from a clean tree. However, this has a side-effect; Make considers
the files included by '-include' are optional. Hence, Make continues
to build even if it fails to generate include/config/auto.conf. I will
change this in the next commit, but the warning message is annoying.
(At least, kbuild test robot reports it as a regression.)
With this commit, Kconfig will generate all configuration files together
with the .config and I guess it is a solution good enough to suppress
the warning.
Note:
GNU Make 4.2 or later does not display the warning from the 'include'
directive if include files are successfully generated. See GNU Make
commit 87a5f98d248f ("[SV 102] Don't show unnecessary include file
errors.") However, older GNU Make versions are still widely used.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
syncconfig updates the .config only when sym_change_count > 0, i.e.
any change in config symbols has been detected.
Not only symbols but also comments are contained in the .config file.
If only comments are updated, they are not fed back to the .config,
then the stale comments are left-over. Of course, this is just a
matter of comments, but why not fix it.
I see some scenarios where this happens.
Scenario A:
1. You have a source tree that has already been configured.
2. Linus increments the version number in the top-level Makefile
(i.e. he commits a new release)
3. You pull it, and run 'make'
4. syncconfig is invoked because the environment variable,
KERNELVERSION is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains a kernel version in the top line:
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.18.0-rc2 Kernel Configuration
... which points to a previous version.
Scenario B:
1. You have a source tree that has already been configured.
2. You upgrade the compiler, but it still has the same version number.
This may happen if you regularly build the latest compiler from
the source code.
3. You run 'make'
4. syncconfig is invoked because the environment variable,
CC_VERSION_TEXT is updated, but the .config is not updated since
no config symbol is changed.
5. The .config file contains the version string of the compiler:
#
# Compiler: aarch64-linux-gcc (GCC) 9.0.0 20180628 (experimental)
#
... which carries the information of the old compiler.
If KCONFIG_NOSILENTUPDATE is set, syncconfig is not allowed to update
the .config file. Otherwise, it is fine to update it regardless of
sym_change_count.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
'make syncconfig' creates some files such as include/config/auto.conf,
include/generate/autoconf.h, etc. but the necessary directory creation
relies on scripts/kconfig/Makefile.
To make Kconfig self-contained, create directories as needed in
conf_write_autoconf().
This change allows scripts/kconfig/Makefile cleanups; syncconfig can
be merged into simple-targets.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Commit 17263baf95 ("kconfig: Create include/generated for
localmodconfig") added the 'mkdir' line because local{yes,mod}config
ran streamline_config.pl followed by silentoldconfig at that time.
Since commit 81d2bc2273 ("kconfig: invoke oldconfig instead of
silentoldconfig from local*config"), no sub-directory is required.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Split out helpers:
is_present() - check if the given path exists
is_dir() - check if the given path exists and it is a directory
make_parent_dir() - create the parent directories of the given path
These helpers will be reused in later commits.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
file_write_dep() is called only from conf_write_autoconf().
Move it from util.c to confdata.c to make it static.
Also, rename it to conf_write_dep() since it should belong to
the group of conf_write* functions.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As you see in mconf.c and nconf.c, conf_message_callback() hooks are
likely to end up with the boilerplate of vsnprintf(). Process the
string format before calling conf_message_callback() so that it
receives a simple string.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Dirk Gouders <dirk@gouders.net>
Over time, the use of the flag SYMBOL_AUTO changed from initially
marking three automatically generated symbols ARCH, KERNELRELEASE and
UNAME_RELEASE to today's effect of protecting symbols from being
written out.
Currently, only symbols of type CHOICE and those with option
defconf_list set have that flag set.
Reflect that change in semantics in the flag's name.
Signed-off-by: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
that other required files are present and to determine build flags
settings, but none of these check that pkg-config itself is present.
Add a check for all 4 of these targets and update
Documentation/process/changes.rst to mention 'pkg-config'.
Fixes kernel bugzilla #77511:
https://bugzilla.kernel.org/show_bug.cgi?id=77511
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
