[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Thomas De Schampheleire]

This patch series reworks the uclibc/busybox config file handling, based on
following requirements:

- neither foo-menuconfig nor foo-update-config should have a dependency on
  the toolchain (which means we cannot depend on foo-configure)
- 'clean foo-menuconfig' should start from the specified (custom) config
  file
- 'foo-menuconfig foo-update-config' should preserve the changes made in the
  menuconfig step (this problem is reported for uclibc with bug #7154
  (https://bugs.busybox.net/show_bug.cgi?id=7154).

The series currently covers uclibc and busybox only, while the problem seems
to be present for linux too. It is submitted as an RFC for this reason, as
I'm unsure if there are comments on the approach.

Thanks for your feedback...

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/busybox/busybox.mk |  28 +++++++++++++++++++---------
 package/uclibc/uclibc.mk   |  16 +++++++++++++---
 2 files changed, 32 insertions(+), 12 deletions(-)

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

When uclibc-menuconfig is executed from a clean repo, and a custom
configuration file was set, then these custom settings are ignored and
uclibc starts from the default configuration.

This patch adds an explicit copy of the custom config file to the menuconfig
target to fix 'make clean uclibc-menuconfig'.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/uclibc/uclibc.mk |  7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff -r 5ea6db6a0838 -r 97d74ccbe054 package/uclibc/uclibc.mk
--- a/package/uclibc/uclibc.mk	Fri Jun 20 23:38:46 2014 +0200
+++ b/package/uclibc/uclibc.mk	Sun Jun 22 10:37:22 2014 +0200
@@ -413,8 +413,11 @@
 	UCLIBC_EXTRA_CFLAGS="$(UCLIBC_EXTRA_CFLAGS) $(TARGET_ABI)" \
 	HOSTCC="$(HOSTCC)"
 
+define UCLIBC_COPY_DOT_CONFIG
+	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(UCLIBC_DIR)/.config
+endef
+
 define UCLIBC_SETUP_DOT_CONFIG
-	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@D)/.config
 	$(call UCLIBC_OPT_SET,CROSS_COMPILER_PREFIX,"$(TARGET_CROSS)",$(@D))
 	$(call UCLIBC_OPT_SET,TARGET_$(UCLIBC_TARGET_ARCH),y,$(@D))
 	$(call UCLIBC_OPT_SET,TARGET_ARCH,"$(UCLIBC_TARGET_ARCH)",$(@D))
@@ -454,6 +457,7 @@
 endef
 
 define UCLIBC_CONFIGURE_CMDS
+	$(UCLIBC_COPY_DOT_CONFIG)
 	$(UCLIBC_SETUP_DOT_CONFIG)
 	$(MAKE1) -C $(UCLIBC_DIR) \
 		$(UCLIBC_MAKE_FLAGS) \
@@ -543,6 +547,7 @@
 endef
 
 uclibc-menuconfig: uclibc-patch
+	$(UCLIBC_COPY_DOT_CONFIG)
 	$(MAKE1) -C $(UCLIBC_DIR) \
 		$(UCLIBC_MAKE_FLAGS) \
 		PREFIX=$(STAGING_DIR) \

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Yann E. MORIN]

Thomas, All,

On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
> When uclibc-menuconfig is executed from a clean repo, and a custom
> configuration file was set, then these custom settings are ignored and
> uclibc starts from the default configuration.
> 
> This patch adds an explicit copy of the custom config file to the menuconfig
> target to fix 'make clean uclibc-menuconfig'.
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/uclibc/uclibc.mk |  7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff -r 5ea6db6a0838 -r 97d74ccbe054 package/uclibc/uclibc.mk
> --- a/package/uclibc/uclibc.mk	Fri Jun 20 23:38:46 2014 +0200
> +++ b/package/uclibc/uclibc.mk	Sun Jun 22 10:37:22 2014 +0200
> @@ -413,8 +413,11 @@
>  	UCLIBC_EXTRA_CFLAGS="$(UCLIBC_EXTRA_CFLAGS) $(TARGET_ABI)" \
>  	HOSTCC="$(HOSTCC)"
>  
> +define UCLIBC_COPY_DOT_CONFIG
> +	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(UCLIBC_DIR)/.config
> +endef
> +
>  define UCLIBC_SETUP_DOT_CONFIG
> -	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@D)/.config
>  	$(call UCLIBC_OPT_SET,CROSS_COMPILER_PREFIX,"$(TARGET_CROSS)",$(@D))
>  	$(call UCLIBC_OPT_SET,TARGET_$(UCLIBC_TARGET_ARCH),y,$(@D))
>  	$(call UCLIBC_OPT_SET,TARGET_ARCH,"$(UCLIBC_TARGET_ARCH)",$(@D))
> @@ -454,6 +457,7 @@
>  endef
>  
>  define UCLIBC_CONFIGURE_CMDS
> +	$(UCLIBC_COPY_DOT_CONFIG)
>  	$(UCLIBC_SETUP_DOT_CONFIG)
>  	$(MAKE1) -C $(UCLIBC_DIR) \
>  		$(UCLIBC_MAKE_FLAGS) \
> @@ -543,6 +547,7 @@
>  endef
>  
>  uclibc-menuconfig: uclibc-patch
> +	$(UCLIBC_COPY_DOT_CONFIG)
>  	$(MAKE1) -C $(UCLIBC_DIR) \
>  		$(UCLIBC_MAKE_FLAGS) \
>  		PREFIX=$(STAGING_DIR) \
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sun, 22 Jun 2014 15:45:40 +0200, Thomas De Schampheleire wrote:

>  uclibc-menuconfig: uclibc-patch
> +	$(UCLIBC_COPY_DOT_CONFIG)

But then if I repeatedly do several uclibc-menuconfig to adjust the
configuration, before restarting the build, I'm going to loose my
changes, no?

Say that UCLIBC_CONFIG_FILE=package/uclibc/uclibc-0.9.33.x.config, and
the following sequence of event:

 1/ Make uclibc-menuconfig. The $(UCLIBC_CONFIG_FILE) gets copied to
    $(BUILD_DIR)/uclibc-<version>/.config.

    I make a change in the uClibc configuration. It gets saved as
    $(BUILD_DIR)/uclibc-<version>/.config.

 2/ I do make uclibc-menuconfig again, because I forgot something. The
    $(UCLIBC_CONFIG_FILE) gets copied to
    $(BUILD_DIR)/uclibc-<version>/.config. I've lost the change I've
    made in step (1).

Am I missing something?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> schreef:
>Dear Thomas De Schampheleire,
>
>On Sun, 22 Jun 2014 15:45:40 +0200, Thomas De Schampheleire wrote:
>
>>  uclibc-menuconfig: uclibc-patch
>> +	$(UCLIBC_COPY_DOT_CONFIG)
>
>But then if I repeatedly do several uclibc-menuconfig to adjust the
>configuration, before restarting the build, I'm going to loose my
>changes, no?
>
>Say that UCLIBC_CONFIG_FILE=package/uclibc/uclibc-0.9.33.x.config, and
>the following sequence of event:
>
> 1/ Make uclibc-menuconfig. The $(UCLIBC_CONFIG_FILE) gets copied to
>    $(BUILD_DIR)/uclibc-<version>/.config.
>
>    I make a change in the uClibc configuration. It gets saved as
>    $(BUILD_DIR)/uclibc-<version>/.config.
>
> 2/ I do make uclibc-menuconfig again, because I forgot something. The
>    $(UCLIBC_CONFIG_FILE) gets copied to
>    $(BUILD_DIR)/uclibc-<version>/.config. I've lost the change I've
>    made in step (1).
>
>Am I missing something?

No, I think you are right. We'll need an intermediate target in between, that it's run once after a clean I guess...

Best regards,
Thomas

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Danomi Manchego]

How about moving the XXX_COPY_CONFIG to the top of the
.stamp_config_file_fixed actions, and then make xxxx-menuconfig update
on that too?

That might be nicer than, say, changing the added COPY in the
xxxx-menuconfig to a "[ -f $(XXXX_BUILD_CONFIG) ] ||
$(XXXX_COPY_CONFIG)"

Danomi -

On Sun, Jun 22, 2014 at 1:23 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> schreef:
>>Dear Thomas De Schampheleire,
>>
>>On Sun, 22 Jun 2014 15:45:40 +0200, Thomas De Schampheleire wrote:
>>
>>>  uclibc-menuconfig: uclibc-patch
>>> +    $(UCLIBC_COPY_DOT_CONFIG)
>>
>>But then if I repeatedly do several uclibc-menuconfig to adjust the
>>configuration, before restarting the build, I'm going to loose my
>>changes, no?
>>
>>Say that UCLIBC_CONFIG_FILE=package/uclibc/uclibc-0.9.33.x.config, and
>>the following sequence of event:
>>
>> 1/ Make uclibc-menuconfig. The $(UCLIBC_CONFIG_FILE) gets copied to
>>    $(BUILD_DIR)/uclibc-<version>/.config.
>>
>>    I make a change in the uClibc configuration. It gets saved as
>>    $(BUILD_DIR)/uclibc-<version>/.config.
>>
>> 2/ I do make uclibc-menuconfig again, because I forgot something. The
>>    $(UCLIBC_CONFIG_FILE) gets copied to
>>    $(BUILD_DIR)/uclibc-<version>/.config. I've lost the change I've
>>    made in step (1).
>>
>>Am I missing something?
>
> No, I think you are right. We'll need an intermediate target in between, that it's run once after a clean I guess...
>
> Best regards,
> Thomas
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

Hi Danomi,

On Sun, Jun 22, 2014 at 7:29 PM, Danomi Manchego
<danomimanchego123@gmail.com> wrote:
> How about moving the XXX_COPY_CONFIG to the top of the
> .stamp_config_file_fixed actions, and then make xxxx-menuconfig update
> on that too?
>
> That might be nicer than, say, changing the added COPY in the
> xxxx-menuconfig to a "[ -f $(XXXX_BUILD_CONFIG) ] ||
> $(XXXX_COPY_CONFIG)"

I'm not sure I fully get what you mean, can you elaborate?

Note that there is another problem in this patch: when running 'make
clean xxx-update-config', the config does not yet exist. This case
should be handled too.

Best regards,
Thomas

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Danomi Manchego]

On Sun, Jun 22, 2014 at 2:52 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Danomi,
>
> On Sun, Jun 22, 2014 at 7:29 PM, Danomi Manchego
> <danomimanchego123@gmail.com> wrote:
>> How about moving the XXX_COPY_CONFIG to the top of the
>> .stamp_config_file_fixed actions, and then make xxxx-menuconfig update
>> on that too?
>>
>> That might be nicer than, say, changing the added COPY in the
>> xxxx-menuconfig to a "[ -f $(XXXX_BUILD_CONFIG) ] ||
>> $(XXXX_COPY_CONFIG)"
>
> I'm not sure I fully get what you mean, can you elaborate?

I was actually looking more at the busybox mods than the uclibc mods.
The busybox .stamp_config_file_fixed target doesn't do the COPY
action.   My thinking is that the COPY only needs to be done once; so
using a stamp target that runs the XXXX_COPY_CONFIG seems suitable.
Then all the make targets that did a COPY, and the targets that you're
patching to do a COPY, can instead depend on such a stamp.  The
.stamp_config_file_fixed targets seem like good candidates - have the
COPY done once before any other targets that assume it's been done,
and then don't do it again.

Danomi -

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

Hi Danomi,

On Sun, Jun 22, 2014 at 9:07 PM, Danomi Manchego
<danomimanchego123@gmail.com> wrote:
> On Sun, Jun 22, 2014 at 2:52 PM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> Hi Danomi,
>>
>> On Sun, Jun 22, 2014 at 7:29 PM, Danomi Manchego
>> <danomimanchego123@gmail.com> wrote:
>>> How about moving the XXX_COPY_CONFIG to the top of the
>>> .stamp_config_file_fixed actions, and then make xxxx-menuconfig update
>>> on that too?
>>>
>>> That might be nicer than, say, changing the added COPY in the
>>> xxxx-menuconfig to a "[ -f $(XXXX_BUILD_CONFIG) ] ||
>>> $(XXXX_COPY_CONFIG)"
>>
>> I'm not sure I fully get what you mean, can you elaborate?
>
> I was actually looking more at the busybox mods than the uclibc mods.
> The busybox .stamp_config_file_fixed target doesn't do the COPY
> action.   My thinking is that the COPY only needs to be done once; so
> using a stamp target that runs the XXXX_COPY_CONFIG seems suitable.
> Then all the make targets that did a COPY, and the targets that you're
> patching to do a COPY, can instead depend on such a stamp.  The
> .stamp_config_file_fixed targets seem like good candidates - have the
> COPY done once before any other targets that assume it's been done,
> and then don't do it again.

The copy cannot be added to the config_file_fixed target, because we
need a separate target that does _not_ do a copy, to be used from the
update_config target...

Best regards,
Thomas

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Arnout Vandecappelle]

On 22/06/14 15:45, Thomas De Schampheleire wrote:
> When uclibc-menuconfig is executed from a clean repo, and a custom
> configuration file was set, then these custom settings are ignored and
> uclibc starts from the default configuration.
> 
> This patch adds an explicit copy of the custom config file to the menuconfig
> target to fix 'make clean uclibc-menuconfig'.
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> 
> ---
>  package/uclibc/uclibc.mk |  7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff -r 5ea6db6a0838 -r 97d74ccbe054 package/uclibc/uclibc.mk
> --- a/package/uclibc/uclibc.mk	Fri Jun 20 23:38:46 2014 +0200
> +++ b/package/uclibc/uclibc.mk	Sun Jun 22 10:37:22 2014 +0200
> @@ -413,8 +413,11 @@
>  	UCLIBC_EXTRA_CFLAGS="$(UCLIBC_EXTRA_CFLAGS) $(TARGET_ABI)" \
>  	HOSTCC="$(HOSTCC)"
>  
> +define UCLIBC_COPY_DOT_CONFIG
> +	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(UCLIBC_DIR)/.config
> +endef
> +
>  define UCLIBC_SETUP_DOT_CONFIG
> -	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@D)/.config
>  	$(call UCLIBC_OPT_SET,CROSS_COMPILER_PREFIX,"$(TARGET_CROSS)",$(@D))
>  	$(call UCLIBC_OPT_SET,TARGET_$(UCLIBC_TARGET_ARCH),y,$(@D))
>  	$(call UCLIBC_OPT_SET,TARGET_ARCH,"$(UCLIBC_TARGET_ARCH)",$(@D))
> @@ -454,6 +457,7 @@
>  endef
>  
>  define UCLIBC_CONFIGURE_CMDS
> +	$(UCLIBC_COPY_DOT_CONFIG)
>  	$(UCLIBC_SETUP_DOT_CONFIG)
>  	$(MAKE1) -C $(UCLIBC_DIR) \
>  		$(UCLIBC_MAKE_FLAGS) \
> @@ -543,6 +547,7 @@
>  endef
>  
>  uclibc-menuconfig: uclibc-patch
> +	$(UCLIBC_COPY_DOT_CONFIG)
>  	$(MAKE1) -C $(UCLIBC_DIR) \
>  		$(UCLIBC_MAKE_FLAGS) \
>  		PREFIX=$(STAGING_DIR) \

 In order to cover all requirements, I think we should rely on real dependencies
here. Something like:

uclibc-menuconfig: $(UCLIBC_DIR)/.config
	$(MAKE1) -C $(UCLIBC_DIR) ...
	$(UCLIBC_FIXUP_DOT_CONFIG)

$(UCLIBC_DIR)/.config: $(UCLIBC_CONFIG_FILE) uclibc-patch
	$(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@)
	$(MAKE1) -C $(UCLIBC_DIR) ... oldconfig
	$(UCLIBC_FIXUP_DOT_CONFIG)

uclibc-configure: $(UCLIBC_DIR)/.config


(I renamed SETUP_DOT_CONFIG to FIXUP_DOT_CONFIG which I think is more accurate.)


 This is obviously just a skeleton, but you can see where I'm going... The
important thing is:

- all config targets depend on .config
- .config depends on the the CONFIG_FILE
- all config targets and .config itself call to FIXUP_DOT_CONFIG


 Regards,
 Arnout

> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

Hi Arnout, all,

On Wed, Jun 25, 2014 at 8:16 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 22/06/14 15:45, Thomas De Schampheleire wrote:
>> When uclibc-menuconfig is executed from a clean repo, and a custom
>> configuration file was set, then these custom settings are ignored and
>> uclibc starts from the default configuration.
>>
>> This patch adds an explicit copy of the custom config file to the menuconfig
>> target to fix 'make clean uclibc-menuconfig'.
>>
>> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>>
>> ---
>>  package/uclibc/uclibc.mk |  7 ++++++-
>>  1 files changed, 6 insertions(+), 1 deletions(-)
>>
>> diff -r 5ea6db6a0838 -r 97d74ccbe054 package/uclibc/uclibc.mk
>> --- a/package/uclibc/uclibc.mk        Fri Jun 20 23:38:46 2014 +0200
>> +++ b/package/uclibc/uclibc.mk        Sun Jun 22 10:37:22 2014 +0200
>> @@ -413,8 +413,11 @@
>>       UCLIBC_EXTRA_CFLAGS="$(UCLIBC_EXTRA_CFLAGS) $(TARGET_ABI)" \
>>       HOSTCC="$(HOSTCC)"
>>
>> +define UCLIBC_COPY_DOT_CONFIG
>> +     $(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(UCLIBC_DIR)/.config
>> +endef
>> +
>>  define UCLIBC_SETUP_DOT_CONFIG
>> -     $(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@D)/.config
>>       $(call UCLIBC_OPT_SET,CROSS_COMPILER_PREFIX,"$(TARGET_CROSS)",$(@D))
>>       $(call UCLIBC_OPT_SET,TARGET_$(UCLIBC_TARGET_ARCH),y,$(@D))
>>       $(call UCLIBC_OPT_SET,TARGET_ARCH,"$(UCLIBC_TARGET_ARCH)",$(@D))
>> @@ -454,6 +457,7 @@
>>  endef
>>
>>  define UCLIBC_CONFIGURE_CMDS
>> +     $(UCLIBC_COPY_DOT_CONFIG)
>>       $(UCLIBC_SETUP_DOT_CONFIG)
>>       $(MAKE1) -C $(UCLIBC_DIR) \
>>               $(UCLIBC_MAKE_FLAGS) \
>> @@ -543,6 +547,7 @@
>>  endef
>>
>>  uclibc-menuconfig: uclibc-patch
>> +     $(UCLIBC_COPY_DOT_CONFIG)
>>       $(MAKE1) -C $(UCLIBC_DIR) \
>>               $(UCLIBC_MAKE_FLAGS) \
>>               PREFIX=$(STAGING_DIR) \
>
>  In order to cover all requirements, I think we should rely on real dependencies
> here. Something like:
>
> uclibc-menuconfig: $(UCLIBC_DIR)/.config
>         $(MAKE1) -C $(UCLIBC_DIR) ...
>         $(UCLIBC_FIXUP_DOT_CONFIG)
>
> $(UCLIBC_DIR)/.config: $(UCLIBC_CONFIG_FILE) uclibc-patch
>         $(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@)
>         $(MAKE1) -C $(UCLIBC_DIR) ... oldconfig
>         $(UCLIBC_FIXUP_DOT_CONFIG)
>
> uclibc-configure: $(UCLIBC_DIR)/.config
>
>
> (I renamed SETUP_DOT_CONFIG to FIXUP_DOT_CONFIG which I think is more accurate.)
>
>
>  This is obviously just a skeleton, but you can see where I'm going... The
> important thing is:
>
> - all config targets depend on .config
> - .config depends on the the CONFIG_FILE
> - all config targets and .config itself call to FIXUP_DOT_CONFIG
>

FYI, my plan for this patch series is to first fix all issues for
uclibc, then extract that to a kconfig-package, then convert busybox,
barebox, linux to this kconfig-package, one by one.

With respect to the skeleton above: you moved the FIXUP_DOT_CONFIG to
the .config and menuconfig target. If a user manually edits .config
(or copies over a new file) then these fixups will not be applied. I
think they should be applied nevertheless, so moving the fixup to the
configure command and letting configure depend on .config makes more
sense to me.

Would you agree?

Thanks,
Thomas

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Arnout Vandecappelle]

On 30/06/14 21:31, Thomas De Schampheleire wrote:
> Hi Arnout, all,
> 
> On Wed, Jun 25, 2014 at 8:16 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
[snip]
>>  In order to cover all requirements, I think we should rely on real dependencies
>> here. Something like:
>>
>> uclibc-menuconfig: $(UCLIBC_DIR)/.config
>>         $(MAKE1) -C $(UCLIBC_DIR) ...
>>         $(UCLIBC_FIXUP_DOT_CONFIG)
>>
>> $(UCLIBC_DIR)/.config: $(UCLIBC_CONFIG_FILE) uclibc-patch
>>         $(INSTALL) -m 0644 $(UCLIBC_CONFIG_FILE) $(@)
>>         $(MAKE1) -C $(UCLIBC_DIR) ... oldconfig
>>         $(UCLIBC_FIXUP_DOT_CONFIG)
>>
>> uclibc-configure: $(UCLIBC_DIR)/.config
>>
>>
>> (I renamed SETUP_DOT_CONFIG to FIXUP_DOT_CONFIG which I think is more accurate.)
>>
>>
>>  This is obviously just a skeleton, but you can see where I'm going... The
>> important thing is:
>>
>> - all config targets depend on .config
>> - .config depends on the the CONFIG_FILE
>> - all config targets and .config itself call to FIXUP_DOT_CONFIG
>>
> 
> FYI, my plan for this patch series is to first fix all issues for
> uclibc, then extract that to a kconfig-package, then convert busybox,
> barebox, linux to this kconfig-package, one by one.
> 
> With respect to the skeleton above: you moved the FIXUP_DOT_CONFIG to
> the .config and menuconfig target. If a user manually edits .config
> (or copies over a new file) then these fixups will not be applied. I
> think they should be applied nevertheless, so moving the fixup to the
> configure command and letting configure depend on .config makes more
> sense to me.
> 
> Would you agree?

 I don't really agree that we should care about a user manually overwriting
.config (so _not_ using a 'make xxxconfig'. However, if we can support that, so
much the better of course.

 Moving the fixup to the configure step has the disadvantage that there is a
difference between:

make clean; make uclibc-menuconfig; make uclibc-update-defconfig

and

make clean; make uclibc-menuconfig; make; make uclibc-update-defconfig

(the first case will not have the fixups applied, the second case does).

 Also, with 'make clean; make uclibc-menuconfig' you'll won't see the result of
the fixups in your menuconfig, which is pretty strange. Especially for e.g.
linux-menuconfig, because 'make clean; make linux-menuconfig' would give you the
config options for i386 instead of your target...


 That said, it doesn't hurt to just put the fixups everywhere: in the .config
target, in the -menuconfig target, and in the PRE_CONFIGURE_HOOKS.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 1 of 5 RFC] uclibc: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

Hi Arnout,

On Tue, Jul 1, 2014 at 8:09 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
[..]
>>
>> FYI, my plan for this patch series is to first fix all issues for
>> uclibc, then extract that to a kconfig-package, then convert busybox,
>> barebox, linux to this kconfig-package, one by one.
>>
>> With respect to the skeleton above: you moved the FIXUP_DOT_CONFIG to
>> the .config and menuconfig target. If a user manually edits .config
>> (or copies over a new file) then these fixups will not be applied. I
>> think they should be applied nevertheless, so moving the fixup to the
>> configure command and letting configure depend on .config makes more
>> sense to me.
>>
>> Would you agree?
>
>  I don't really agree that we should care about a user manually overwriting
> .config (so _not_ using a 'make xxxconfig'. However, if we can support that, so
> much the better of course.
>
>  Moving the fixup to the configure step has the disadvantage that there is a
> difference between:
>
> make clean; make uclibc-menuconfig; make uclibc-update-defconfig
>
> and
>
> make clean; make uclibc-menuconfig; make; make uclibc-update-defconfig
>
> (the first case will not have the fixups applied, the second case does).

Yes, but this is why in patch 2/5 I also added the FIXUP step to the
update-defconfig target. After this, both sequences should give the
same result.

>
>  Also, with 'make clean; make uclibc-menuconfig' you'll won't see the result of
> the fixups in your menuconfig, which is pretty strange. Especially for e.g.
> linux-menuconfig, because 'make clean; make linux-menuconfig' would give you the
> config options for i386 instead of your target...

For linux, the menuconfig step depends on the -configure step, and the
configure commands include the copy + fixup of the config file. This
works fine with respect to what you wrote above, but has the
disadvantage that the entire toolchain has to be built/downloaded
before being able to set the linux config (which violates one of the
stated requirements).

>
>
>  That said, it doesn't hurt to just put the fixups everywhere: in the .config
> target, in the -menuconfig target, and in the PRE_CONFIGURE_HOOKS.

I think it indeed boils down to adding the fixup to the right places
to get the right, expected behavior, without the downsides that we
already discovered...

Best regards,
Thomas

[Buildroot] [PATCH 2 of 5 RFC] uclibc: update-config: preserve freshly configured settings

[Thomas De Schampheleire]

In the sequence:

make uclibc-menuconfig
make uclibc-update-config

the freshly configured settings from the menuconfig are lost during the
update-config step. This is because update-config depends on the configure
step, which starts by copying the config file to the build directory.

Instead, stop depending on the configure step from update-config, and
explicitly call the needed commands before actually copying the config file.

This has the added bonus that 'uclibc-update-config' no longer needs the
toolchain to be available, which makes:
    make clean uclibc-menuconfig uclibc-update-config
much faster and user-friendly.

Fixes bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/uclibc/uclibc.mk |  9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff -r 97d74ccbe054 -r 62a7dd35bfbf package/uclibc/uclibc.mk
--- a/package/uclibc/uclibc.mk	Sun Jun 22 10:37:22 2014 +0200
+++ b/package/uclibc/uclibc.mk	Mon Jun 16 20:18:23 2014 +0200
@@ -554,11 +554,16 @@
 		DEVEL_PREFIX=/usr/ \
 		RUNTIME_PREFIX=$(STAGING_DIR)/ \
 		menuconfig
-	rm -f $(UCLIBC_DIR)/.stamp_{configured,built,target_installed,staging_installed}
+	rm -f $(UCLIBC_DIR)/.stamp_{config_file_fixed,configured,built}
+	rm -f $(UCLIBC_DIR)/.stamp_{target_installed,staging_installed}
 
 $(eval $(generic-package))
 
-uclibc-update-config: $(UCLIBC_DIR)/.stamp_configured
+$(UCLIBC_DIR)/.stamp_config_file_fixed:
+	$(UCLIBC_SETUP_DOT_CONFIG)
+	touch $@
+
+uclibc-update-config: $(UCLIBC_DIR)/.stamp_config_file_fixed
 	cp -f $(UCLIBC_DIR)/.config $(UCLIBC_CONFIG_FILE)
 
 # Before uClibc is built, we must have the second stage cross-compiler

[Buildroot] [PATCH 2 of 5 RFC] uclibc: update-config: preserve freshly configured settings

[Yann E. MORIN]

Thomas, All,

On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
> In the sequence:
> 
> make uclibc-menuconfig
> make uclibc-update-config
> 
> the freshly configured settings from the menuconfig are lost during the
> update-config step. This is because update-config depends on the configure
> step, which starts by copying the config file to the build directory.
> 
> Instead, stop depending on the configure step from update-config, and
> explicitly call the needed commands before actually copying the config file.
> 
> This has the added bonus that 'uclibc-update-config' no longer needs the
> toolchain to be available, which makes:
>     make clean uclibc-menuconfig uclibc-update-config
> much faster and user-friendly.
> 
> Fixes bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/uclibc/uclibc.mk |  9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff -r 97d74ccbe054 -r 62a7dd35bfbf package/uclibc/uclibc.mk
> --- a/package/uclibc/uclibc.mk	Sun Jun 22 10:37:22 2014 +0200
> +++ b/package/uclibc/uclibc.mk	Mon Jun 16 20:18:23 2014 +0200
> @@ -554,11 +554,16 @@
>  		DEVEL_PREFIX=/usr/ \
>  		RUNTIME_PREFIX=$(STAGING_DIR)/ \
>  		menuconfig
> -	rm -f $(UCLIBC_DIR)/.stamp_{configured,built,target_installed,staging_installed}
> +	rm -f $(UCLIBC_DIR)/.stamp_{config_file_fixed,configured,built}
> +	rm -f $(UCLIBC_DIR)/.stamp_{target_installed,staging_installed}
>  
>  $(eval $(generic-package))
>  
> -uclibc-update-config: $(UCLIBC_DIR)/.stamp_configured
> +$(UCLIBC_DIR)/.stamp_config_file_fixed:
> +	$(UCLIBC_SETUP_DOT_CONFIG)
> +	touch $@
> +
> +uclibc-update-config: $(UCLIBC_DIR)/.stamp_config_file_fixed
>  	cp -f $(UCLIBC_DIR)/.config $(UCLIBC_CONFIG_FILE)
>  
>  # Before uClibc is built, we must have the second stage cross-compiler
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 3 of 5 RFC] busybox: fix typo overwritting

[Thomas De Schampheleire]

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/busybox/busybox.mk |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff -r 62a7dd35bfbf -r 6bb6b3f59fd5 package/busybox/busybox.mk
--- a/package/busybox/busybox.mk	Mon Jun 16 20:18:23 2014 +0200
+++ b/package/busybox/busybox.mk	Sun Jun 22 15:29:01 2014 +0200
@@ -189,7 +189,7 @@
 endef
 endif
 
-# Enable "noclobber" in install.sh, to prevent BusyBox from overwritting any
+# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any
 # full-blown versions of apps installed by other packages with sym/hard links.
 define BUSYBOX_NOCLOBBER_INSTALL
 	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh

[Buildroot] [PATCH 3 of 5 RFC] busybox: fix typo overwritting

[Yann E. MORIN]

Thomas, All,

On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/busybox/busybox.mk |  2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff -r 62a7dd35bfbf -r 6bb6b3f59fd5 package/busybox/busybox.mk
> --- a/package/busybox/busybox.mk	Mon Jun 16 20:18:23 2014 +0200
> +++ b/package/busybox/busybox.mk	Sun Jun 22 15:29:01 2014 +0200
> @@ -189,7 +189,7 @@
>  endef
>  endif
>  
> -# Enable "noclobber" in install.sh, to prevent BusyBox from overwritting any
> +# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any
>  # full-blown versions of apps installed by other packages with sym/hard links.
>  define BUSYBOX_NOCLOBBER_INSTALL
>  	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 4 of 5 RFC] busybox: menuconfig: take into account initial settings from config file

[Thomas De Schampheleire]

When busybox-menuconfig is executed from a clean repo, and a custom
configuration file was set, then these custom settings are ignored and
busybox starts from the default configuration.

This patch adds an explicit copy of the custom config file to the menuconfig
target to fix 'make clean busybox-menuconfig'.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/busybox/busybox.mk |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff -r 6bb6b3f59fd5 -r 5dc5438c0108 package/busybox/busybox.mk
--- a/package/busybox/busybox.mk	Sun Jun 22 15:29:01 2014 +0200
+++ b/package/busybox/busybox.mk	Sun Jun 22 15:33:49 2014 +0200
@@ -232,6 +232,7 @@
 $(eval $(generic-package))
 
 busybox-menuconfig busybox-xconfig busybox-gconfig: busybox-patch
+	$(BUSYBOX_COPY_CONFIG)
 	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(BUSYBOX_DIR) \
 		$(subst busybox-,,$@)
 	rm -f $(BUSYBOX_DIR)/.stamp_built

[Buildroot] [PATCH 4 of 5 RFC] busybox: menuconfig: take into account initial settings from config file

[Yann E. MORIN]

Thomas, All,

On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
> When busybox-menuconfig is executed from a clean repo, and a custom
> configuration file was set, then these custom settings are ignored and
> busybox starts from the default configuration.
> 
> This patch adds an explicit copy of the custom config file to the menuconfig
> target to fix 'make clean busybox-menuconfig'.
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/busybox/busybox.mk |  1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff -r 6bb6b3f59fd5 -r 5dc5438c0108 package/busybox/busybox.mk
> --- a/package/busybox/busybox.mk	Sun Jun 22 15:29:01 2014 +0200
> +++ b/package/busybox/busybox.mk	Sun Jun 22 15:33:49 2014 +0200
> @@ -232,6 +232,7 @@
>  $(eval $(generic-package))
>  
>  busybox-menuconfig busybox-xconfig busybox-gconfig: busybox-patch
> +	$(BUSYBOX_COPY_CONFIG)
>  	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(BUSYBOX_DIR) \
>  		$(subst busybox-,,$@)
>  	rm -f $(BUSYBOX_DIR)/.stamp_built
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 5 of 5 RFC] busybox: update-config: preserve freshly configured settings

[Thomas De Schampheleire]

In the sequence:

make busybox-menuconfig
make busybox-update-config

the freshly configured settings from the menuconfig are lost during the
update-config step. This is because update-config depends on the configure
step, which starts by copying the config file to the build directory.

Instead, stop depending on the configure step from update-config, and
explicitly call the needed commands before actually copying the config file.

This has the added bonus that 'busybox-update-config' no longer needs the
toolchain to be available, which makes:
    make clean busybox-menuconfig busybox-update-config
much faster and user-friendly.

This is a corrolary of bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/busybox/busybox.mk |  27 ++++++++++++++++++---------
 1 files changed, 18 insertions(+), 9 deletions(-)

diff -r 5dc5438c0108 -r 7e80ee0110a2 package/busybox/busybox.mk
--- a/package/busybox/busybox.mk	Sun Jun 22 15:33:49 2014 +0200
+++ b/package/busybox/busybox.mk	Sun Jun 22 10:34:06 2014 +0200
@@ -189,14 +189,7 @@
 endef
 endif
 
-# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any
-# full-blown versions of apps installed by other packages with sym/hard links.
-define BUSYBOX_NOCLOBBER_INSTALL
-	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh
-endef
-
-define BUSYBOX_CONFIGURE_CMDS
-	$(BUSYBOX_COPY_CONFIG)
+define BUSYBOX_SETUP_CONFIG
 	$(BUSYBOX_SET_MMU)
 	$(BUSYBOX_SET_LARGEFILE)
 	$(BUSYBOX_SET_IPV6)
@@ -208,6 +201,17 @@
 	$(BUSYBOX_INTERNAL_SHADOW_PASSWORDS)
 	$(BUSYBOX_SET_INIT)
 	$(BUSYBOX_SET_WATCHDOG)
+endef
+
+# Enable "noclobber" in install.sh, to prevent BusyBox from overwritting any
+# full-blown versions of apps installed by other packages with sym/hard links.
+define BUSYBOX_NOCLOBBER_INSTALL
+	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh
+endef
+
+define BUSYBOX_CONFIGURE_CMDS
+	$(BUSYBOX_COPY_CONFIG)
+	$(BUSYBOX_SETUP_CONFIG)
 	@yes "" | $(MAKE) ARCH=$(KERNEL_ARCH) CROSS_COMPILE="$(TARGET_CROSS)" \
 		-C $(@D) oldconfig
 	$(BUSYBOX_NOCLOBBER_INSTALL)
@@ -235,8 +239,13 @@
 	$(BUSYBOX_COPY_CONFIG)
 	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(BUSYBOX_DIR) \
 		$(subst busybox-,,$@)
+	rm -f $(BUSYBOX_DIR)/.stamp_config_file_fixed
 	rm -f $(BUSYBOX_DIR)/.stamp_built
 	rm -f $(BUSYBOX_DIR)/.stamp_target_installed
 
-busybox-update-config: busybox-configure
+$(BUSYBOX_DIR)/.stamp_config_file_fixed:
+	$(BUSYBOX_SETUP_CONFIG)
+	touch $@
+
+busybox-update-config: $(BUSYBOX_DIR)/.stamp_config_file_fixed
 	cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)

[Buildroot] [PATCH 5 of 5 RFC] busybox: update-config: preserve freshly configured settings

[Yann E. MORIN]

Thomas, All,

On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
> In the sequence:
> 
> make busybox-menuconfig
> make busybox-update-config
> 
> the freshly configured settings from the menuconfig are lost during the
> update-config step. This is because update-config depends on the configure
> step, which starts by copying the config file to the build directory.
> 
> Instead, stop depending on the configure step from update-config, and
> explicitly call the needed commands before actually copying the config file.
> 
> This has the added bonus that 'busybox-update-config' no longer needs the
> toolchain to be available, which makes:
>     make clean busybox-menuconfig busybox-update-config
> much faster and user-friendly.
> 
> This is a corrolary of bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

There is a small typo below, which when fixed, would get my:
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

> ---
>  package/busybox/busybox.mk |  27 ++++++++++++++++++---------
>  1 files changed, 18 insertions(+), 9 deletions(-)
> 
> diff -r 5dc5438c0108 -r 7e80ee0110a2 package/busybox/busybox.mk
> --- a/package/busybox/busybox.mk	Sun Jun 22 15:33:49 2014 +0200
> +++ b/package/busybox/busybox.mk	Sun Jun 22 10:34:06 2014 +0200
> @@ -189,14 +189,7 @@
>  endef
>  endif
>  
> -# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any
> -# full-blown versions of apps installed by other packages with sym/hard links.
> -define BUSYBOX_NOCLOBBER_INSTALL
> -	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh
> -endef
> -
> -define BUSYBOX_CONFIGURE_CMDS
> -	$(BUSYBOX_COPY_CONFIG)
> +define BUSYBOX_SETUP_CONFIG
>  	$(BUSYBOX_SET_MMU)
>  	$(BUSYBOX_SET_LARGEFILE)
>  	$(BUSYBOX_SET_IPV6)
> @@ -208,6 +201,17 @@
>  	$(BUSYBOX_INTERNAL_SHADOW_PASSWORDS)
>  	$(BUSYBOX_SET_INIT)
>  	$(BUSYBOX_SET_WATCHDOG)
> +endef
> +
> +# Enable "noclobber" in install.sh, to prevent BusyBox from overwritting any

Hehe. You're introducing the 'overwritting' typo back? ;-)

Regards,
Yann E. MORIN.

> +# full-blown versions of apps installed by other packages with sym/hard links.
> +define BUSYBOX_NOCLOBBER_INSTALL
> +	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh
> +endef
> +
> +define BUSYBOX_CONFIGURE_CMDS
> +	$(BUSYBOX_COPY_CONFIG)
> +	$(BUSYBOX_SETUP_CONFIG)
>  	@yes "" | $(MAKE) ARCH=$(KERNEL_ARCH) CROSS_COMPILE="$(TARGET_CROSS)" \
>  		-C $(@D) oldconfig
>  	$(BUSYBOX_NOCLOBBER_INSTALL)
> @@ -235,8 +239,13 @@
>  	$(BUSYBOX_COPY_CONFIG)
>  	$(BUSYBOX_MAKE_ENV) $(MAKE) $(BUSYBOX_MAKE_OPTS) -C $(BUSYBOX_DIR) \
>  		$(subst busybox-,,$@)
> +	rm -f $(BUSYBOX_DIR)/.stamp_config_file_fixed
>  	rm -f $(BUSYBOX_DIR)/.stamp_built
>  	rm -f $(BUSYBOX_DIR)/.stamp_target_installed
>  
> -busybox-update-config: busybox-configure
> +$(BUSYBOX_DIR)/.stamp_config_file_fixed:
> +	$(BUSYBOX_SETUP_CONFIG)
> +	touch $@
> +
> +busybox-update-config: $(BUSYBOX_DIR)/.stamp_config_file_fixed
>  	cp -f $(BUSYBOX_BUILD_CONFIG) $(BUSYBOX_CONFIG_FILE)
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 5 of 5 RFC] busybox: update-config: preserve freshly configured settings

[Thomas De Schampheleire]

"Yann E. MORIN" <yann.morin.1998@free.fr> schreef:
>Thomas, All,
>
>On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
>> In the sequence:
>> 
>> make busybox-menuconfig
>> make busybox-update-config
>> 
>> the freshly configured settings from the menuconfig are lost during the
>> update-config step. This is because update-config depends on the configure
>> step, which starts by copying the config file to the build directory.
>> 
>> Instead, stop depending on the configure step from update-config, and
>> explicitly call the needed commands before actually copying the config file.
>> 
>> This has the added bonus that 'busybox-update-config' no longer needs the
>> toolchain to be available, which makes:
>>     make clean busybox-menuconfig busybox-update-config
>> much faster and user-friendly.
>> 
>> This is a corrolary of bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154
>> 
>> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
>
>Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
>There is a small typo below, which when fixed, would get my:
>Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
>> ---
>>  package/busybox/busybox.mk |  27 ++++++++++++++++++---------
>>  1 files changed, 18 insertions(+), 9 deletions(-)
>> 
>> diff -r 5dc5438c0108 -r 7e80ee0110a2 package/busybox/busybox.mk
>> --- a/package/busybox/busybox.mk	Sun Jun 22 15:33:49 2014 +0200
>> +++ b/package/busybox/busybox.mk	Sun Jun 22 10:34:06 2014 +0200
>> @@ -189,14 +189,7 @@
>>  endef
>>  endif
>>  
>> -# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any
>> -# full-blown versions of apps installed by other packages with sym/hard links.
>> -define BUSYBOX_NOCLOBBER_INSTALL
>> -	$(SED) 's/^noclobber="0"$$/noclobber="1"/' $(@D)/applets/install.sh
>> -endef
>> -
>> -define BUSYBOX_CONFIGURE_CMDS
>> -	$(BUSYBOX_COPY_CONFIG)
>> +define BUSYBOX_SETUP_CONFIG
>>  	$(BUSYBOX_SET_MMU)
>>  	$(BUSYBOX_SET_LARGEFILE)
>>  	$(BUSYBOX_SET_IPV6)
>> @@ -208,6 +201,17 @@
>>  	$(BUSYBOX_INTERNAL_SHADOW_PASSWORDS)
>>  	$(BUSYBOX_SET_INIT)
>>  	$(BUSYBOX_SET_WATCHDOG)
>> +endef
>> +
>> +# Enable "noclobber" in install.sh, to prevent BusyBox from overwritting any
>
>Hehe. You're introducing the 'overwritting' typo back? ;-)

Darn, bad reject handling on my side... well spotted!

Thanks for the review and tests. So it seems you are fine with the approach?

Best regards,
Thomas

[Buildroot] [PATCH 5 of 5 RFC] busybox: update-config: preserve freshly configured settings

[Yann E. MORIN]

Thomas, All,

On 2014-06-22 16:22 +0200, Thomas De Schampheleire spake thusly:
> "Yann E. MORIN" <yann.morin.1998@free.fr> schreef:
> >On 2014-06-22 15:45 +0200, Thomas De Schampheleire spake thusly:
> >> In the sequence:
> >> 
> >> make busybox-menuconfig
> >> make busybox-update-config
> >> 
> >> the freshly configured settings from the menuconfig are lost during the
> >> update-config step. This is because update-config depends on the configure
> >> step, which starts by copying the config file to the build directory.
> >> 
> >> Instead, stop depending on the configure step from update-config, and
> >> explicitly call the needed commands before actually copying the config file.
> >> 
> >> This has the added bonus that 'busybox-update-config' no longer needs the
> >> toolchain to be available, which makes:
> >>     make clean busybox-menuconfig busybox-update-config
> >> much faster and user-friendly.
> >> 
> >> This is a corrolary of bug #7154 https://bugs.busybox.net/show_bug.cgi?id=7154
> >> 
> >> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[--SNIP--]
> Thanks for the review and tests. So it seems you are fine with the approach?

It looks Ok to me. We do need these new behaviours.

As for the code, I only marked it Reviewed-by for what it means. I am
not not sure enough to mak it Acked-by, although I don't see a better
way to do it. Thomas and Peter have a better understanding on all this
stuff, so I'll leave the last call to them. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Arnout Vandecappelle]

 Hi Thomas,

On 22/06/14 15:45, Thomas De Schampheleire wrote:
> 
> This patch series reworks the uclibc/busybox config file handling, based on
> following requirements:
> 
> - neither foo-menuconfig nor foo-update-config should have a dependency on
>   the toolchain (which means we cannot depend on foo-configure)
> - 'clean foo-menuconfig' should start from the specified (custom) config
>   file
> - 'foo-menuconfig foo-update-config' should preserve the changes made in the
>   menuconfig step (this problem is reported for uclibc with bug #7154
>   (https://bugs.busybox.net/show_bug.cgi?id=7154).

 I agree with these requirements. With of course the additional requirement
mentioned by ThomasP:

- 'make foo-menuconfig; make foo-menuconfig' should preserve the changes made in
the menuconfig step.

 However, I think it would be better to add infrastructure for kconfig packages,
instead of repeating the work for uclibc, busybox, linux and barebox. I was
thinking along the lines of:

$(eval $(generic-package))

LINUX_KCONFIG_TARGETS = menuconfig xconfig gconfig nconfig
LINUX_HAS_DEFCONFIG = YES

$(eval $(kconfig-package))



 Regards,
 Arnout

> 
> The series currently covers uclibc and busybox only, while the problem seems
> to be present for linux too. It is submitted as an RFC for this reason, as
> I'm unsure if there are comments on the approach.
> 
> Thanks for your feedback...
> 
> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
> 
> ---
>  package/busybox/busybox.mk |  28 +++++++++++++++++++---------
>  package/uclibc/uclibc.mk   |  16 +++++++++++++---
>  2 files changed, 32 insertions(+), 12 deletions(-)
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Thomas De Schampheleire]

Hi Arnout,

On Wed, Jun 25, 2014 at 8:06 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>  Hi Thomas,
>
> On 22/06/14 15:45, Thomas De Schampheleire wrote:
>>
>> This patch series reworks the uclibc/busybox config file handling, based on
>> following requirements:
>>
>> - neither foo-menuconfig nor foo-update-config should have a dependency on
>>   the toolchain (which means we cannot depend on foo-configure)
>> - 'clean foo-menuconfig' should start from the specified (custom) config
>>   file
>> - 'foo-menuconfig foo-update-config' should preserve the changes made in the
>>   menuconfig step (this problem is reported for uclibc with bug #7154
>>   (https://bugs.busybox.net/show_bug.cgi?id=7154).
>
>  I agree with these requirements. With of course the additional requirement
> mentioned by ThomasP:
>
> - 'make foo-menuconfig; make foo-menuconfig' should preserve the changes made in
> the menuconfig step.

And additionally:

- 'make clean foo-update-config' should copy the initial file, do any
fixups, and then save the config

>
>  However, I think it would be better to add infrastructure for kconfig packages,
> instead of repeating the work for uclibc, busybox, linux and barebox. I was
> thinking along the lines of:
>
> $(eval $(generic-package))
>
> LINUX_KCONFIG_TARGETS = menuconfig xconfig gconfig nconfig
> LINUX_HAS_DEFCONFIG = YES
>
> $(eval $(kconfig-package))
>
>

This sounds like a very interesting idea, I'll explore it further in
the context of this patch series.

Best regards,
Thomas

[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Thomas De Schampheleire]

On Wed, Jun 25, 2014 at 9:24 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Arnout,
>
> On Wed, Jun 25, 2014 at 8:06 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>  Hi Thomas,
>>
>> On 22/06/14 15:45, Thomas De Schampheleire wrote:
>>>
>>> This patch series reworks the uclibc/busybox config file handling, based on
>>> following requirements:
>>>
>>> - neither foo-menuconfig nor foo-update-config should have a dependency on
>>>   the toolchain (which means we cannot depend on foo-configure)
>>> - 'clean foo-menuconfig' should start from the specified (custom) config
>>>   file
>>> - 'foo-menuconfig foo-update-config' should preserve the changes made in the
>>>   menuconfig step (this problem is reported for uclibc with bug #7154
>>>   (https://bugs.busybox.net/show_bug.cgi?id=7154).
>>
>>  I agree with these requirements. With of course the additional requirement
>> mentioned by ThomasP:
>>
>> - 'make foo-menuconfig; make foo-menuconfig' should preserve the changes made in
>> the menuconfig step.
>
> And additionally:
>
> - 'make clean foo-update-config' should copy the initial file, do any
> fixups, and then save the config
>
>>
>>  However, I think it would be better to add infrastructure for kconfig packages,
>> instead of repeating the work for uclibc, busybox, linux and barebox. I was
>> thinking along the lines of:
>>
>> $(eval $(generic-package))
>>
>> LINUX_KCONFIG_TARGETS = menuconfig xconfig gconfig nconfig
>> LINUX_HAS_DEFCONFIG = YES
>>
>> $(eval $(kconfig-package))
>>
>>
>
> This sounds like a very interesting idea, I'll explore it further in
> the context of this patch series.

I'm working on this now, but I wonder which is the right approach wrt
the organization of the patch series:

- first line up linux, busybox, uclibc in the way they handle the
kconfig stuff, then extract this to a kconfig-package framework
- or first introduce a kconfig-package framework with the 'right'
handling, then convert each of linux, busybox, uclibc in subsequent
patches?

Thanks,
Thomas

[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sun, 29 Jun 2014 10:13:28 +0200, Thomas De Schampheleire wrote:

> > This sounds like a very interesting idea, I'll explore it further in
> > the context of this patch series.
> 
> I'm working on this now, but I wonder which is the right approach wrt
> the organization of the patch series:
> 
> - first line up linux, busybox, uclibc in the way they handle the
> kconfig stuff, then extract this to a kconfig-package framework
> - or first introduce a kconfig-package framework with the 'right'
> handling, then convert each of linux, busybox, uclibc in subsequent
> patches?

I'd say it doesn't matter that much. Maybe the first one allows more
easily to see the functional changes that are made, by really I don't
think it matter. At least on my end, I'd be happy with any of those two
solutions.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 0 of 5 RFC] uclibc/busybox: fix handling of configuration file

[Arnout Vandecappelle]

On 29/06/14 10:20, Thomas Petazzoni wrote:
> Dear Thomas De Schampheleire,
> 
> On Sun, 29 Jun 2014 10:13:28 +0200, Thomas De Schampheleire wrote:
> 
>>> This sounds like a very interesting idea, I'll explore it further in
>>> the context of this patch series.
>>
>> I'm working on this now, but I wonder which is the right approach wrt
>> the organization of the patch series:
>>
>> - first line up linux, busybox, uclibc in the way they handle the
>> kconfig stuff, then extract this to a kconfig-package framework
>> - or first introduce a kconfig-package framework with the 'right'
>> handling, then convert each of linux, busybox, uclibc in subsequent
>> patches?
> 
> I'd say it doesn't matter that much. Maybe the first one allows more
> easily to see the functional changes that are made, by really I don't
> think it matter. At least on my end, I'd be happy with any of those two
> solutions.

 Same here. I had thought about it and found arguments for both options, so I
thought it better not to say anything :-)

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F