diff mbox

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

Message ID 97d74ccbe054d9a16465.1403444740@localhost
State RFC
Headers show

Commit Message

Thomas De Schampheleire June 22, 2014, 1:45 p.m. UTC 
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(-)

Comments

Yann E. MORIN June 22, 2014, 2:05 p.m. UTC | #1 
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@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni June 22, 2014, 4:52 p.m. UTC | #2 
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 De Schampheleire June 22, 2014, 5:23 p.m. UTC | #3 
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
Danomi Manchego June 22, 2014, 5:29 p.m. UTC | #4 
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@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Thomas De Schampheleire June 22, 2014, 6:52 p.m. UTC | #5 
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
Danomi Manchego June 22, 2014, 7:07 p.m. UTC | #6 
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 -
Thomas De Schampheleire June 24, 2014, 6:35 p.m. UTC | #7 
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
Arnout Vandecappelle June 25, 2014, 6:16 a.m. UTC | #8 
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@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Thomas De Schampheleire June 30, 2014, 7:31 p.m. UTC | #9 
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
Arnout Vandecappelle July 1, 2014, 6:09 a.m. UTC | #10 
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
Thomas De Schampheleire July 1, 2014, 8:35 a.m. UTC | #11 
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
diff mbox

Patch

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) \