core/pkg-kconfig: use olddefconfig when available

From: Romain Izard <romain.izard.pro@gmail.com>

Using 'yes "" | make oldconfig' to regenerate a .config file from an
existing defconfig does not work reliably in all cases. Specifically, it
does not work well with tristate choice entries.

The correct way to do it is to use 'make olddefconfig', but this target
is not supported in projects that use an old version of kconfig. As
most projects do not use tristate entries, there is no need for them to
upgrade.

'oldnoconfig' is an alias for 'olddefconfig', but it also is the only
name for this target between Linux versions 2.6.36 and 3.6.

Check which targets are supported by the current project, and use the
appropriate method to regenerate the .config file.

Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
[yann.morin.1998@free.fr: use a shell construct instead of makefile code]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

---
Note: the helper to extract the make rule could very well be made more
generic, by passing the make command to run instead of passing the
package name. However, there is no need for it for now, and that would
make thecalls to that macro a little bit longer (e.g. for a kconfig
package):
    $$(call MAKE_RULE,$$($(2)_KCONFIG_MAKE),oldconfig)
This far from unreadable, but since there is no need for a generic
wrapper for, we keep it as-is. When/if there is such a need, we can
revisit it.

---
Changelog:
v1: New patch
v2: Use oldnoconfig instead of olddefconfig
    Fix silent mode
    Change the pattern in both places where it is used
    Use a macro to avoid redundancy
v3: Do not use $(call ...)
    Use the $(2)_KCONFIG_MAKE variable
v4: No change
v5: Detect available methods and use the most recent one
v6: Remove colon from matched rule names
v7: Use shell construct, not makefile code  (Yann)
---
 package/pkg-kconfig.mk | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

Hello,

On Sat, 23 Apr 2016 19:46:04 +0200, Yann E. MORIN wrote:

> +# Helper to extract the make rule specified in $(2) from all the make rules
> +# of the package specified in $(1).
> +# Returns a non-empty string (the rule itself) of the rule exist; returns

of the rule exist -> if the rule exists

> +# The correct way to regenerate a .config file is to use 'make olddefconfig'.
> +# For historical reasons, the target name is 'oldnoconfig' between Linux kernel

I believe it sounded better with:

 "the target name *was* 'oldnoconfig' ..."

I've applied after fixing those minor nits! Thanks Romain and Yann for
working on this topic!

Best regards,

Thomas

Hello,

On Sat, 23 Apr 2016 19:46:04 +0200, Yann E. MORIN wrote:
> From: Romain Izard <romain.izard.pro@gmail.com>
> 
> Using 'yes "" | make oldconfig' to regenerate a .config file from an
> existing defconfig does not work reliably in all cases. Specifically, it
> does not work well with tristate choice entries.
> 
> The correct way to do it is to use 'make olddefconfig', but this target
> is not supported in projects that use an old version of kconfig. As
> most projects do not use tristate entries, there is no need for them to
> upgrade.
> 
> 'oldnoconfig' is an alias for 'olddefconfig', but it also is the only
> name for this target between Linux versions 2.6.36 and 3.6.
> 
> Check which targets are supported by the current project, and use the
> appropriate method to regenerate the .config file.
> 
> Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
> [yann.morin.1998@free.fr: use a shell construct instead of makefile code]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

I am sorry, but I had to revert this commit. While it works in simple
situations, it badly breaks the Busybox build in some situations:

  http://autobuild.buildroot.org/?reason=busybox-1.24.2

With just Busybox enabled in a minimal configuration, everything is
fine. Enable "libtirpc" in the configuration, do a full rebuild ->
Busybox will fail to build. I don't know if it's related specifically
to libtirpc or to some of its dependencies, but it fails.

A very quick research couldn't spot the source of the problem, so I
simply reverted for now. Could you work on this and submit a new
version of the patch that addresses this problem?

Thanks!

Thomas

2016-04-25 15:35 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> I am sorry, but I had to revert this commit. While it works in simple
> situations, it badly breaks the Busybox build in some situations:
>
>   http://autobuild.buildroot.org/?reason=busybox-1.24.2
>
> With just Busybox enabled in a minimal configuration, everything is
> fine. Enable "libtirpc" in the configuration, do a full rebuild ->
> Busybox will fail to build. I don't know if it's related specifically
> to libtirpc or to some of its dependencies, but it fails.
>
> A very quick research couldn't spot the source of the problem, so I
> simply reverted for now. Could you work on this and submit a new
> version of the patch that addresses this problem?
>

When testing with qemu_x86_defconfig, libtirpc and busybox I reproduce
the issue. Calling 'make busybox-menuconfig' returns errors when
updating the config file to merge buildroot-managed options with the new
busybox config file, as it tries to launch olddefconfig.

The first error in the build is "bash: command not found".

There is a problem with the shell command we tried to generate, as the
command line contains multiple levels of backticks. This comes from
libtirpc, which uses backticks to generate its CFLAGS.

It is possible to fix this by replacing the backticks in the
(2)_REGEN_DOT_CONFIG macro. Unfortunately, $(...) is detected by
make as its own syntax, so it is necessarily to use quadruple dollars.

The v6 revision of the patch, as it did not use backticks, did not have
this problem.

Best regards,

Romain, All,

On 2016-04-25 18:42 +0200, Romain Izard spake thusly:
> 2016-04-25 15:35 GMT+02:00 Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>:
> > Hello,
> >
> > I am sorry, but I had to revert this commit. While it works in simple
> > situations, it badly breaks the Busybox build in some situations:
> >
> >   http://autobuild.buildroot.org/?reason=busybox-1.24.2
> >
> > With just Busybox enabled in a minimal configuration, everything is
> > fine. Enable "libtirpc" in the configuration, do a full rebuild ->
> > Busybox will fail to build. I don't know if it's related specifically
> > to libtirpc or to some of its dependencies, but it fails.
> >
> > A very quick research couldn't spot the source of the problem, so I
> > simply reverted for now. Could you work on this and submit a new
> > version of the patch that addresses this problem?
> >
> 
> When testing with qemu_x86_defconfig, libtirpc and busybox I reproduce
> the issue. Calling 'make busybox-menuconfig' returns errors when
> updating the config file to merge buildroot-managed options with the new
> busybox config file, as it tries to launch olddefconfig.
> 
> The first error in the build is "bash: command not found".
> 
> There is a problem with the shell command we tried to generate, as the
> command line contains multiple levels of backticks. This comes from
> libtirpc, which uses backticks to generate its CFLAGS.

No, it does not come from libtirpc. It comes from the busybox package,
see:
    https://git.buildroot.org/buildroot/tree/package/busybox/busybox.mk#n23
    https://git.buildroot.org/buildroot/tree/package/busybox/busybox.mk#n26

And that's really the reason why I dislike back-quotes...

However, because our .mk are written in Makefile, and we can't always
know the number of expansion the Makefile variables will undergo, we
can't safely use $(xxx) to replace `xxx`... Sad... :-(

> It is possible to fix this by replacing the backticks in the
> (2)_REGEN_DOT_CONFIG macro. Unfortunately, $(...) is detected by
> make as its own syntax, so it is necessarily to use quadruple dollars.

Meh... Peolple like to think they'd be happier if they had more $, but
really more $ really hurts! ;-p

> The v6 revision of the patch, as it did not use backticks, did not have
> this problem.

I'm afraid we'll have to resort to using the makefile syntax, indeed...

Romain, could you please respin your latest revision that was using the
Makefile syntax? IIRC, I did add my reviewed-by tag to it, so you can
keep it (unless you were to tweak the code). However, please add an
explanation in the commit log that we can't use shell constructs,
something along the lines of:

    We use a Makefile syntax because using a shell construct does not
    work:
      - some packages may have shell-expansion in their _KCONFIG_OPTS
      - we can't safely use $() for command substituion, so we have to
        use ``
      - `` does not nest nicely
    Using a shell construct here to check the rule, would mean using ``,
    which could conflict with the `` from the package's _KCONFIG_OPTS.

(Feel free to adapt or re-use as-is! ;-) )

Tyanks!

Regards,
Yann E. MORIN.