Searched hist:e19b0fb4851f8b6371d91adb34c68c3566140d3f (Results 1 – 3 of 3) sorted by relevance
/openbmc/u-boot/scripts/ |
H A D | Makefile.autoconf | e19b0fb4851f8b6371d91adb34c68c3566140d3f Sun Sep 25 23:05:01 CDT 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 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>
|
H A D | Makefile.spl | e19b0fb4851f8b6371d91adb34c68c3566140d3f Sun Sep 25 23:05:01 CDT 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 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>
|
/openbmc/u-boot/ |
H A D | Makefile | e19b0fb4851f8b6371d91adb34c68c3566140d3f Sun Sep 25 23:05:01 CDT 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 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>
|