Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
On Wed, Jul 30, 2014 at 08:08:02PM -0600, Stephen Warren wrote: On 07/30/2014 07:56 PM, Masahiro Yamada wrote: Hi Stephen, On Wed, 30 Jul 2014 17:05:21 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/29/2014 11:08 PM, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. This is quite unfortunate; it breaks any scripts that were building U-Boot via make board_config; make. Can't we add another rule to allow the old build commands to work? Technically, yes. I think we can. But I do not like having it permanently. So, we support both *_defconfig and *_config for a while (maybe 6 months or so?) and then remove *_config. Deal? If the old command-line is ever going to be removed, there's no point supporting both at all; I'd have to hack my scripts to support both sometime, so I may as well do it now rather than wait. Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that... Do you mean, you need to build some different versions of U-boot ? Yes. I own some scripts that build U-Boot, and they need to work on any reasonable version of U-Boot that anyone might want to build. For example, they build 2014.07 just fine, and there's no reason they should ever stop being able to do that. I obviously also want my scripts to be able to build any future version of U-Boot. So long as we have MAKEALL (and we'll have the discussion about moving to buildman sometime soon) this just becomes: if [ -x tools/genboardscfg.py ]; then tools/genboardscfg.py fi MAKEALL machine-name -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
On 07/31/2014 02:34 PM, Tom Rini wrote: On Wed, Jul 30, 2014 at 08:08:02PM -0600, Stephen Warren wrote: On 07/30/2014 07:56 PM, Masahiro Yamada wrote: Hi Stephen, On Wed, 30 Jul 2014 17:05:21 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/29/2014 11:08 PM, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. This is quite unfortunate; it breaks any scripts that were building U-Boot via make board_config; make. Can't we add another rule to allow the old build commands to work? Technically, yes. I think we can. But I do not like having it permanently. So, we support both *_defconfig and *_config for a while (maybe 6 months or so?) and then remove *_config. Deal? If the old command-line is ever going to be removed, there's no point supporting both at all; I'd have to hack my scripts to support both sometime, so I may as well do it now rather than wait. Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that... Do you mean, you need to build some different versions of U-boot ? Yes. I own some scripts that build U-Boot, and they need to work on any reasonable version of U-Boot that anyone might want to build. For example, they build 2014.07 just fine, and there's no reason they should ever stop being able to do that. I obviously also want my scripts to be able to build any future version of U-Boot. So long as we have MAKEALL (and we'll have the discussion about moving to buildman sometime soon) this just becomes: if [ -x tools/genboardscfg.py ]; then tools/genboardscfg.py fi MAKEALL machine-name There's now a large disadvantage to MAKEALL; it takes longer to run that to build U-Boot itself, since it must auto-generate boards.cfg. Perhaps that's only done once, or when the data changes. Also, is MAKEALL an/the official way to build U-Boot, or just a useful tool? I have the impression that running make is the official way to build U-Boot, but MAKEALL/buildman are useful wrapper tools if you want to do batch builds etc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
On 31-07-14 22:55, Stephen Warren wrote: On 07/31/2014 02:34 PM, Tom Rini wrote: On Wed, Jul 30, 2014 at 08:08:02PM -0600, Stephen Warren wrote: On 07/30/2014 07:56 PM, Masahiro Yamada wrote: Hi Stephen, On Wed, 30 Jul 2014 17:05:21 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/29/2014 11:08 PM, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. This is quite unfortunate; it breaks any scripts that were building U-Boot via make board_config; make. Can't we add another rule to allow the old build commands to work? Technically, yes. I think we can. But I do not like having it permanently. So, we support both *_defconfig and *_config for a while (maybe 6 months or so?) and then remove *_config. Deal? If the old command-line is ever going to be removed, there's no point supporting both at all; I'd have to hack my scripts to support both sometime, so I may as well do it now rather than wait. Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that... Do you mean, you need to build some different versions of U-boot ? Yes. I own some scripts that build U-Boot, and they need to work on any reasonable version of U-Boot that anyone might want to build. For example, they build 2014.07 just fine, and there's no reason they should ever stop being able to do that. I obviously also want my scripts to be able to build any future version of U-Boot. So long as we have MAKEALL (and we'll have the discussion about moving to buildman sometime soon) this just becomes: if [ -x tools/genboardscfg.py ]; then tools/genboardscfg.py fi MAKEALL machine-name There's now a large disadvantage to MAKEALL; it takes longer to run that to build U-Boot itself, since it must auto-generate boards.cfg. Perhaps that's only done once, or when the data changes. there is, it is _terribly_ slow when dealing with warnings in the build. MAKEALL is much better for that. Replacing the _config rule with _defconfig is just a bad idea afaic. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
On Wed, Jul 30, 2014 at 02:08:17PM +0900, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. It will create the .config file and additionally spl/.config, tpl/.config if SPL, TPL is enabled, respectively. You can use make config, make menuconfig etc. to create a new .config or modify the existing one. Use make spl/config, make spl/menuconfig etc. for spl/.config and do likewise for tpl/.config file. The generic syntax of configuration targets for SPL, TPL is: target_image/config_command Here, target_image is either 'spl' or 'tpl' config_command is 'config', 'menuconfig', 'xconfig', etc. When the configuration is done, run make. (Or make board_defconfig all will do the configuration and build in one time.) For futher information of how Kconfig works in U-Boot, please read the comment block of scripts/multiconfig.py. By the way, there is another item worth remarking here: coexistence of Kconfig and board herder files. Prior to Kconfig, we used C headers to define a set of configs. We expect a very long term to migrate from C headers to Kconfig. Two different infractructure must coexist in the interim. In our former configuration scheme, include/autoconf.mk was generated for use in makefiles. It is still generated under include/, spl/include/, tpl/include/ directory for the Normal, SPL, TPL image, respectively. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
On 07/29/2014 11:08 PM, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. This is quite unfortunate; it breaks any scripts that were building U-Boot via make board_config; make. Can't we add another rule to allow the old build commands to work? Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
Hi Stephen, On Wed, 30 Jul 2014 17:05:21 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/29/2014 11:08 PM, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. This is quite unfortunate; it breaks any scripts that were building U-Boot via make board_config; make. Can't we add another rule to allow the old build commands to work? Technically, yes. I think we can. But I do not like having it permanently. So, we support both *_defconfig and *_config for a while (maybe 6 months or so?) and then remove *_config. Deal? Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that... Do you mean, you need to build some different versions of U-boot ? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
On 07/30/2014 07:56 PM, Masahiro Yamada wrote: Hi Stephen, On Wed, 30 Jul 2014 17:05:21 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 07/29/2014 11:08 PM, Masahiro Yamada wrote: This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. This is quite unfortunate; it breaks any scripts that were building U-Boot via make board_config; make. Can't we add another rule to allow the old build commands to work? Technically, yes. I think we can. But I do not like having it permanently. So, we support both *_defconfig and *_config for a while (maybe 6 months or so?) and then remove *_config. Deal? If the old command-line is ever going to be removed, there's no point supporting both at all; I'd have to hack my scripts to support both sometime, so I may as well do it now rather than wait. Otherwise, I guess I'll have to hack my scripts to check whether e.g. scripts/multiconfig.py (which was added in this commit) is present in the tree, and execute different build commands based on that... Do you mean, you need to build some different versions of U-boot ? Yes. I own some scripts that build U-Boot, and they need to work on any reasonable version of U-Boot that anyone might want to build. For example, they build 2014.07 just fine, and there's no reason they should ever stop being able to do that. I obviously also want my scripts to be able to build any future version of U-Boot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 05/13] kconfig: switch to Kconfig
This commit enables Kconfig. Going forward, we use Kconfig for the board configuration. mkconfig will never be used. Nor will include/config.mk be generated. Kconfig must be adjusted for U-Boot because our situation is a little more complicated than Linux Kernel. We have to generate multiple boot images (Normal, SPL, TPL) from one source tree. Each image needs its own configuration input. Usage: Run make board_defconfig to do the board configuration. It will create the .config file and additionally spl/.config, tpl/.config if SPL, TPL is enabled, respectively. You can use make config, make menuconfig etc. to create a new .config or modify the existing one. Use make spl/config, make spl/menuconfig etc. for spl/.config and do likewise for tpl/.config file. The generic syntax of configuration targets for SPL, TPL is: target_image/config_command Here, target_image is either 'spl' or 'tpl' config_command is 'config', 'menuconfig', 'xconfig', etc. When the configuration is done, run make. (Or make board_defconfig all will do the configuration and build in one time.) For futher information of how Kconfig works in U-Boot, please read the comment block of scripts/multiconfig.py. By the way, there is another item worth remarking here: coexistence of Kconfig and board herder files. Prior to Kconfig, we used C headers to define a set of configs. We expect a very long term to migrate from C headers to Kconfig. Two different infractructure must coexist in the interim. In our former configuration scheme, include/autoconf.mk was generated for use in makefiles. It is still generated under include/, spl/include/, tpl/include/ directory for the Normal, SPL, TPL image, respectively. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Acked-by: Simon Glass s...@chromium.org --- Changes in v8: - Add a directory '.' as the first argument of 'find' command as FreeBSD requires it. (Reported by Jeroen) Changes in v7: - Follow PEP8 codiyg style: Use blah blah rather than '''blah blah''' for docstring. Fix some indents Add a period of the end of the first line of docstring - Remove temporary directories '$(objtree)/arch' and '$(objtree)/configs' Changes in v6: Various fixes reported by Simon. - Bug fix make spl:config does not work for out-of-tree build. So, the syntax has been changed to make spl/config. - Rename autoconf_is_update - autoconf_is_current - Fix comments in scripts/multiconfig.py - Use foo: blah blah instead of foo - blah blah for Python comment style. - Sort Python imports alphabetically Changes in v5: - Rebase on commit fbe79a17fd Changes in v4: - Have one defconfig file for each board by supporting conditional definition in defconfig - Put adjustment code into scripts/multiconfig.py Changes in v3: - Invoke SPL/TPL configuration only for defconfig and silentoldconfig Changes in v2: - Put dirty build rule into scripts/multiple_config.sh and scripts/Makefile.autoconf - Fix dependency tracking. In v1, any change to Kconfig triggered re-complile of all objects. In this version, re-compile is kept at a minimum. - Fix a clean-source check In v1, clean source tree check did not work correctly for out-of-tree build. .gitignore| 2 - Makefile | 116 +-- arch/m68k/cpu/mcf52x2/config.mk | 16 +- arch/m68k/cpu/mcf532x/config.mk | 6 +- arch/m68k/cpu/mcf5445x/config.mk | 4 +- arch/powerpc/cpu/ppc4xx/config.mk | 4 +- config.mk | 10 + include/.gitignore| 1 - scripts/Makefile | 2 +- scripts/Makefile.autoconf | 100 ++ scripts/Makefile.build| 31 +-- scripts/Makefile.spl | 31 +-- scripts/basic/fixdep.c| 6 +- scripts/kconfig/confdata.c| 8 + scripts/multiconfig.py| 410 ++ tools/Makefile| 2 +- tools/env/Makefile| 2 +- 17 files changed, 619 insertions(+), 132 deletions(-) create mode 100644 scripts/Makefile.autoconf create mode 100755 scripts/multiconfig.py diff --git a/.gitignore b/.gitignore index 0ace33b..5ac2e60 100644 --- a/.gitignore +++ b/.gitignore @@ -53,8 +53,6 @@ # /include/config/ /include/generated/ -/include/spl-autoconf.mk -/include/tpl-autoconf.mk # stgit generated dirs patches-* diff --git a/Makefile b/Makefile index 80eb239..5e49545 100644 --- a/Makefile +++ b/Makefile @@ -166,9 +166,6 @@ VPATH := $(srctree)$(if $(KBUILD_EXTMOD),:$(KBUILD_EXTMOD)) export srctree objtree VPATH -MKCONFIG := $(srctree)/mkconfig -export MKCONFIG - # Make sure CDPATH settings don't interfere unexport CDPATH @@ -189,9 +186,6 @@ HOSTOS := $(shell uname -s | tr '[:upper:]' '[:lower:]' | \ export HOSTARCH HOSTOS -# Deal with colliding definitions from tcsh etc.
