| e19b0fb4 | 26-Sep-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: generate u-boot.cfg as a byproduct of include/autoconf.mk
Our build system still parses ad-hoc CONFIG options in header files
and generates include/autoconf.mk so that Makefiles can referenc
kbuild: generate u-boot.cfg as a byproduct of include/autoconf.mk
Our build system still parses ad-hoc CONFIG options in header files
and generates include/autoconf.mk so that Makefiles can reference
them. This gimmick was introduced in the pre-Kconfig days and will
be kept until Kconfig migration is completed.
The include/autoconf.mk is generated like follows:
[1] Preprocess include/common.h with -DDO_DEPS_ONLY and
retrieve macros into include/autoconf.mk.tmp
[2] Reformat include/autoconf.mk.dep into include/autoconf.mk
with tools/scripts/define2mk.sed script
[3] Remove include/autoconf.mk.tmp
Here, include/autoconf.mk.tmp is similar to u-boot.cfg, which is
also generated by preprocessing include/config.h with -DDO_DEPS_ONLY.
In other words, there is much overlap among include/autoconf.mk and
u-boot.cfg build rules.
So, the idea is to split the build rule of include/autoconf.mk
into two stages. The first preprocesses headers into u-boot.cfg.
The second parses the u-boot.cfg into include/autoconf.mk. The
build rules of u-boot.cfg in Makefile and spl/Makefile will be gone.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 1406992f | 26-Sep-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: make dependencies in scripts/Makefile.autoconf more readable
I do not remember why I wrote the code like this, but let's make it
a bit more readable.
Signed-off-by: Masahiro Yamada <yamada.
kbuild: make dependencies in scripts/Makefile.autoconf more readable
I do not remember why I wrote the code like this, but let's make it
a bit more readable.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 7b76daab | 26-Sep-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
check-config: fix wrong comment about how to build whitelist
The command suggested in this comment block is wrong; it would not
rip off CONFIG options that had already been converted to Kconfig.
In
check-config: fix wrong comment about how to build whitelist
The command suggested in this comment block is wrong; it would not
rip off CONFIG options that had already been converted to Kconfig.
Instead, we should use the scripts/build-whitelist.sh tool.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 8bb0f7c0 | 26-Sep-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
config_whitelist: remove bogus options
These are not CONFIG options (detected by my eyes).
CONFIG_SPL_BUILD and CONFIG_TPL_BUILD are build options defined only
for building SPL and TPL, respectivel
config_whitelist: remove bogus options
These are not CONFIG options (detected by my eyes).
CONFIG_SPL_BUILD and CONFIG_TPL_BUILD are build options defined only
for building SPL and TPL, respectively.
The others are just mentioned in comment blocks.
Now, scripts/build-whitelist.sh never picks up new options. Once
we kill these false ones, they will never revive.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 1da33a28 | 26-Sep-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
config_whitelist: sync by tool
It is a good practice to drop an option from the whitelist when we
convert it to Kconfig, but we may sometimes forget to do that.
So, it might be a good idea to sync
config_whitelist: sync by tool
It is a good practice to drop an option from the whitelist when we
convert it to Kconfig, but we may sometimes forget to do that.
So, it might be a good idea to sync the whitelist from time to time.
This commit was generated by:
scripts/build-whitelist.sh
Looks like we had a bit progress...
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|
| 9608f43c | 26-Sep-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
build-whitelist: do not add new options to whitelist when update
If somebody adds references to new CONFIG options in source files,
they will be added in the whitelist when we sync it. (For example
build-whitelist: do not add new options to whitelist when update
If somebody adds references to new CONFIG options in source files,
they will be added in the whitelist when we sync it. (For example,
if we run scripts/build-whitelist.sh against commit 42f75050667b,
new options CONFIG_SPL_DFU_SUPPORT and CONFIG_USB_XHCI_UNIPHIER will
appear in the list.)
In order to make steady progress of Kconfig migration, we want to
only decrease whitelist options, but never increase.
So, when we update the whitelist, we should create a temporary list,
then take the intersection of the temporary one and the current one.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
show more ...
|