Add/rename *-update-config targets
PATCH 1/1 Add/rename *-update-config targets
--- linux/linux.mk | 11 +++++++++++ package/busybox/busybox.mk | 2 +- toolchain/uClibc/uclibc.mk | 2 +- 3 files changed, 13 insertions(+), 2 deletions(-)
PATCH 1/1 linux: add linux-update-config and linux-update-defconfig targets
In analogy to build targets uclibc-update and busybox-update, add extra targets to copy the current configuration to the custom configuration file set in buildroot. These targets facilitate the work of developers adding support for a specific board.
linux-update-config copies .config directly. linux-update-defconfig first creates a defconfig and copies that.
---
v2: add defconfig target and rename.
linux/linux.mk | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
linux/linux.mk +11 -0
@@ -190,6 +190,17 @@ $(MAKE) $(LINUX_MAKE_FLAGS) -C $(LINUX_DIR) \ $(subst linux-,,$(subst linux26-,,$@)) +ifeq ($(BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG),y) +linux-update-config linux26-update-config: $(LINUX_DIR)/.config + cp -f $(LINUX_DIR)/.config $(BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE) + +linux-update-defconfig linux26-update-defconfig: linux-savedefconfig + cp -f $(LINUX_DIR)/defconfig $(BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE) +else +linux-update-config linux26-update-config: ; +linux-update-defconfig linux26-update-defconfig: ; +endif + # Support for rebuilding the kernel after the initramfs file list has # been generated in $(BINARIES_DIR)/rootfs.initramfs. $(LINUX_DIR)/.stamp_initramfs_rebuilt: $(LINUX_DIR)/.stamp_target_installed $(LINUX_DIR)/.stamp_images_installed $(BINARIES_DIR)/rootfs.initramfs
PATCH 1/1 busybox: rename busybox-update to busybox-update-config
In reply to Thomas De SchampheleireThe original name busybox-update is confusing as it only updates a configuration file.
--- package/busybox/busybox.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
package/busybox/busybox.mk +1 -1
@@ -184,5 +184,5 @@ rm -f $(BUSYBOX_DIR)/.stamp_built rm -f $(BUSYBOX_DIR)/.stamp_target_installed -busybox-update: +busybox-update-config: cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)
PATCH 1/1 uclibc: rename uclibc-update to uclibc-update-config
In reply to Thomas De SchampheleireThe original name uclibc-update is confusing as it only updates a configuration file.
--- toolchain/uClibc/uclibc.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
toolchain/uClibc/uclibc.mk +1 -1
@@ -500,7 +500,7 @@ uclibc-oldconfig: $(UCLIBC_DIR)/.oldconfig -uclibc-update: uclibc-config +uclibc-update-config: uclibc-config cp -f $(UCLIBC_DIR)/.config $(UCLIBC_CONFIG_FILE) uclibc-configured: gcc_initial kernel-headers $(UCLIBC_DIR)/.configured
PATCH 1/1 linux: add linux-update-config and linux-update-defconfig targets
In reply to Thomas De SchampheleireLe Tue, 27 Sep 2011 21:21:09 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :
Quoted 9 lines
In analogy to build targets uclibc-update and busybox-update, add extra targets to copy the current configuration to the custom configuration file set in buildroot. These targets facilitate the work of developers adding support for a specific board.
linux-update-config copies .config directly. linux-update-defconfig first creates a defconfig and copies that.
Signed-off-by Thomas De Schampheleire <[email protected]>
As further improvements, I am wondering :
* Whether linux-update-*config should display a warning/error when BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE is not used, instead of being silent.
* Whether this configuration update shouldn't be done automatically when one does "make linux-menuconfig" or "make linux-xconfig". People have often found strange to loose their configuration changes in Linux/Busybox/uClibc when they do a make clean.
But regardless of this discussion, I think your patch should be merged as is.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 busybox: rename busybox-update to busybox-update-config
In reply to Thomas De SchampheleireLe Tue, 27 Sep 2011 21:21:10 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :
Quoted 4 lines
The original name busybox-update is confusing as it only updates a configuration file.
Signed-off-by Thomas De Schampheleire <[email protected]>
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 uclibc: rename uclibc-update to uclibc-update-config
In reply to Thomas De SchampheleireLe Tue, 27 Sep 2011 21:21:11 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :
Quoted 4 lines
The original name uclibc-update is confusing as it only updates a configuration file.
Signed-off-by Thomas De Schampheleire <[email protected]>
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 linux: add linux-update-config and linux-update-defconfig targets
In reply to Thomas PetazzoniQuoted 13 lines · Thomas Petazzoni
Le Tue, 27 Sep 2011 21:21:09 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :Quoted 9 lines
In analogy to build targets uclibc-update and busybox-update, add extra targets to copy the current configuration to the custom configuration file set in buildroot. These targets facilitate the work of developers adding support for a specific board.
linux-update-config copies .config directly. linux-update-defconfig first creates a defconfig and copies that.
Signed-off-by Thomas De Schampheleire <[email protected]>
Quoted 7 lines
Acked-by Thomas Petazzoni <[email protected]>As further improvements, I am wondering :
?* Whether linux-update-*config should display a warning/error when ?
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILEis not used, instead of being ? silent.
Ok, that's fine.
Quoted 5 lines
?* Whether this configuration update shouldn't be done automatically ? when one does "make linux-menuconfig" or "make linux-xconfig". ? People have often found strange to loose their configuration changes ? in Linux/Busybox/uClibc when they do a make clean.
Such a feature would be good indeed. But, some remarks:
* hooking it to menuconfig/xconfig wouldn't cover the case where the .config is manually changed. This different behavior may be confusing as well.
What if we execute the automatic saving just before the build step? This of course requires to start building; you cannot just change the config and hope that it is copied automatically. In that last case, a manual linux-update-config would be necessary.
Is this acceptable?
* previously you raised the point of busybox-update / uclibc-update potentially overwriting the standard buildroot files. If we do not want this and we want automatic saving of custom configs, then we need to be able to differentiate between custom and default configuration files.
On the other hand, if there are users that purposefully put their project's configuration in the default files (overwriting them), then they would not be able to benefit from the automatic saving, and possibly not from -update-config either. But I'm not sure if we ought to support such practice...
Quoted 3 lines
But regardless of this discussion, I think your patch should be merged as is.
Thanks for your ack, also on the other patches.
We'll implement the outcome of the newly raised discussion in a separate patch then...
~Thomas
PATCH 1/1 linux: add linux-update-config and linux-update-defconfig targets
Le Wed, 28 Sep 2011 08:08:12 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :
Quoted 9 lines
Quoted 4 lines
?* Whether this configuration update shouldn't be done automatically ? when one does "make linux-menuconfig" or "make linux-xconfig". ? People have often found strange to loose their configuration changes ? in Linux/Busybox/uClibc when they do a make clean.
Such a feature would be good indeed. But, some remarks:
* hooking it to menuconfig/xconfig wouldn't cover the case where the .config is manually changed. This different behavior may be confusing as well.
Correct, even though manually changing the .config is a bit of a corner case.
Quoted 5 lines
What if we execute the automatic saving just before the build step? This of course requires to start building; you cannot just change the config and hope that it is copied automatically. In that last case, a manual linux-update-config would be necessary.
Is this acceptable?
Yes, sounds good.
Quoted 10 lines
* previously you raised the point of busybox-update / uclibc-update potentially overwriting the standard buildroot files. If we do not want this and we want automatic saving of custom configs, then we need to be able to differentiate between custom and default configuration files.
On the other hand, if there are users that purposefully put their project's configuration in the default files (overwriting them), then they would not be able to benefit from the automatic saving, and possibly not from -update-config either. But I'm not sure if we ought to support such practice...
Maybe we can change a bit the selection of the Busybox/uClibc configuration file. We could do something like:
[X] Use default Busybox configuration file
in which case Busybox would use the default configuration file integrated in Buildroot.
If this option is disabled:
[ ] Use default Busybox configuration file (/some/path/busybox.config) Path to Busybox config file
then Buildroot uses the specified configuration file.
With this change, busybox-config-update would output an error if the default config file is used and would work properly if a specific config file is given.
What do you think?
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 linux: add linux-update-config and linux-update-defconfig targets
Quoted 48 lines · Thomas Petazzoni
Le Wed, 28 Sep 2011 08:08:12 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :Quoted 9 lines
Quoted 4 lines
?* Whether this configuration update shouldn't be done automatically ? when one does "make linux-menuconfig" or "make linux-xconfig". ? People have often found strange to loose their configuration changes ? in Linux/Busybox/uClibc when they do a make clean.
Such a feature would be good indeed. But, some remarks:
* hooking it to menuconfig/xconfig wouldn't cover the case where the .config is manually changed. This different behavior may be confusing as well.Correct, even though manually changing the .config is a bit of a corner case.
Quoted 5 lines
What if we execute the automatic saving just before the build step? This of course requires to start building; you cannot just change the config and hope that it is copied automatically. In that last case, a manual linux-update-config would be necessary.
Is this acceptable?Yes, sounds good.
Quoted 10 lines
* previously you raised the point of busybox-update / uclibc-update potentially overwriting the standard buildroot files. If we do not want this and we want automatic saving of custom configs, then we need to be able to differentiate between custom and default configuration files.
On the other hand, if there are users that purposefully put their project's configuration in the default files (overwriting them), then they would not be able to benefit from the automatic saving, and possibly not from -update-config either. But I'm not sure if we ought to support such practice...Maybe we can change a bit the selection of the Busybox/uClibc configuration file. We could do something like:
?[X] Use default Busybox configuration file
in which case Busybox would use the default configuration file integrated in Buildroot.
If this option is disabled:
?[ ] Use default Busybox configuration file ?(/some/path/busybox.config) Path to Busybox config file
Quoted 8 lines
then Buildroot uses the specified configuration file.
With this change, busybox-config-update would output an error if the default config file is used and would work properly if a specific config file is given.
What do you think?
Sounds good to me!
I'm currently a bit busy with switching toolchains, so this will be somewhat delayed. (Unless you have spare time, in which case you are free to jump in)
Thanks,
Thomas