[v3,1/2] randconfig, allyesconfig: fix handling of legacy options

Randconfig and allyesconfig should never select legacy options, so use
the same trick as allpackageyesconfig and randpackageconfig to remove
them.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 Makefile | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

Dear Arnout Vandecappelle (Essensium/Mind),

On Tue, 14 Oct 2014 11:24:54 +0200, Arnout Vandecappelle
(Essensium/Mind) wrote:
> Randconfig and allyesconfig should never select legacy options, so use
> the same trick as allpackageyesconfig and randpackageconfig to remove
> them.
> 
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>  Makefile | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 907a0fc..5bcaa77 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -731,11 +731,25 @@ oldconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>  
>  randconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>  	@mkdir -p $(BUILD_DIR)/buildroot-config
> -	@$(COMMON_CONFIG_ENV) $< --randconfig $(CONFIG_CONFIG_IN)
> +	@rm -f $(CONFIG_DIR)/.config.nopkg
> +	@grep '^config ' Config.in.legacy | \
> +		while read config pkg; do \
> +		echo "# $$pkg is not set" >> $(CONFIG_DIR)/.config.nopkg; done
> +	@$(COMMON_CONFIG_ENV) \
> +		KCONFIG_ALLCONFIG=$(CONFIG_DIR)/.config.nopkg \
> +		$< --randconfig $(CONFIG_CONFIG_IN)
> +	@rm -f $(CONFIG_DIR)/.config.nopkg
>  
>  allyesconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>  	@mkdir -p $(BUILD_DIR)/buildroot-config
> -	@$(COMMON_CONFIG_ENV) $< --allyesconfig $(CONFIG_CONFIG_IN)
> +	@rm -f $(CONFIG_DIR)/.config.nopkg
> +	@grep '^config ' Config.in.legacy | \
> +		while read config pkg; do \
> +		echo "# $$pkg is not set" >> $(CONFIG_DIR)/.config.nopkg; done
> +	@$(COMMON_CONFIG_ENV) \
> +		KCONFIG_ALLCONFIG=$(CONFIG_DIR)/.config.nopkg \
> +		$< --allyesconfig $(CONFIG_CONFIG_IN)
> +	@rm -f $(CONFIG_DIR)/.config.nopkg
>  
>  allnoconfig: $(BUILD_DIR)/buildroot-config/conf outputmakefile
>  	@mkdir -p $(BUILD_DIR)/buildroot-config

I was going to apply this, and then I tested it, to discover that it
then causes the same problem as the one we have with randpackageconfig
today: none of the choice options get randomized anymore. So before
this patch, if you do "randconfig", you get proper randomization. After
this patch, if you do "randconfig", it only generates i386
configurations.

I admit it's not really an issue introduced by the patch as the issue
already exists for randpackageconfig. But it's very annoying :/

Thomas

Hello,

On Thu, 30 Oct 2014 23:03:10 +0100, Thomas Petazzoni wrote:

> I was going to apply this, and then I tested it, to discover that it
> then causes the same problem as the one we have with randpackageconfig
> today: none of the choice options get randomized anymore. So before
> this patch, if you do "randconfig", you get proper randomization. After
> this patch, if you do "randconfig", it only generates i386
> configurations.
> 
> I admit it's not really an issue introduced by the patch as the issue
> already exists for randpackageconfig. But it's very annoying :/

Any comment about this?

Thomas

On 31/12/14 15:17, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 30 Oct 2014 23:03:10 +0100, Thomas Petazzoni wrote:
> 
>> I was going to apply this, and then I tested it, to discover that it
>> then causes the same problem as the one we have with randpackageconfig
>> today: none of the choice options get randomized anymore. So before
>> this patch, if you do "randconfig", you get proper randomization. After
>> this patch, if you do "randconfig", it only generates i386
>> configurations.
>>
>> I admit it's not really an issue introduced by the patch as the issue
>> already exists for randpackageconfig. But it's very annoying :/
> 
> Any comment about this?

 Well, as you explained to me in Dusseldorf, the main reason to use randconfig
is to test against buggy Config.in depends/select chains. If the choices
wouldn't get properly randomized anymore, that would really kill this use case.
So I guess that's a no go.

 Regards,
 Arnout

Dear Arnout Vandecappelle,

On Thu, 08 Jan 2015 21:36:53 +0100, Arnout Vandecappelle wrote:

> >> I admit it's not really an issue introduced by the patch as the issue
> >> already exists for randpackageconfig. But it's very annoying :/
> > 
> > Any comment about this?
> 
>  Well, as you explained to me in Dusseldorf, the main reason to use randconfig
> is to test against buggy Config.in depends/select chains. If the choices
> wouldn't get properly randomized anymore, that would really kill this use case.
> So I guess that's a no go.

Well, the other day, I actually attempted to use randconfig to really
have random configurations, and see how broken they are. But randconfig
is unusable today, since it selects a bunch of legacy options, which
prevents the build from starting.

I'm not sure I actually use randconfig to test buggy Config.in
depends/select. I actually tend to use randpackageconfig: I fix a
certain arch/toolchain combination, and sent to a bit of
randpackageconfig. Which indeed means that I'm not testing everything
since the choices are not randomized.

Do we have a hope of getting properly randomized choices one day. Are
there other options?

Thomas

On 01/08/15 21:43, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Thu, 08 Jan 2015 21:36:53 +0100, Arnout Vandecappelle wrote:
> 
>>>> I admit it's not really an issue introduced by the patch as the issue
>>>> already exists for randpackageconfig. But it's very annoying :/
>>>
>>> Any comment about this?
>>
>>  Well, as you explained to me in Dusseldorf, the main reason to use randconfig
>> is to test against buggy Config.in depends/select chains. If the choices
>> wouldn't get properly randomized anymore, that would really kill this use case.
>> So I guess that's a no go.
> 
> Well, the other day, I actually attempted to use randconfig to really
> have random configurations, and see how broken they are. But randconfig
> is unusable today, since it selects a bunch of legacy options, which
> prevents the build from starting.

The use case that currently does work is:

while true; do make randconfig; done

 If there is something wrong with depends/select chains, you'll get the
occasional error like

warning: (BR2_PACKAGE_FOO) selects BR2_PACKAGE_BAR which has unmet direct
dependencies (!BR2_STATIC_LIBS && BR2_PACKAGE_HAS_UDEV)


 My invalid fix of randconfig would make that use case less relevant, because
the invalid chain may depend on some choice value.


 I guess it must have been Yann who explained it to me, not you :-)


 Regards,
 Arnout