Re: [PATCH] kconfig: add *_silentdefconfig feature for config targets

[Roman Zippel]

Hi,

On Mon, 20 Aug 2007, Andres Salomon wrote:

> AFAICT, there is nothing similar when using *_defconfig; one must copy
> a .config manually, and then run silentoldconfig.  Simply running the
> associated _defconfig will quietly update the config (which may silently
> drop config options).  This patch adds a *_silentdefconfig target, with
> semantics similar to silentoldconfig.  It will take the defconfig from
> arch/$(ARCH)/configs/$x_defconfig, check for changes, and if there are
> none, write out a .config.  If there have been changes and stdin is
> valid, it will prompt for updates.  If there have been changes and
> stdin is not valid, it will bail out with an error.

I would really like to avoid another input mode.
I think it be better to implement this as a combination of "-s -D 
<default>" and the silent mode is adjusted to read another config instead 
of .config if defconfig_file is set.

> A few things to note:
>   - Using getopt() in scripts/kconfig/conf.c would likely simplify things,
>     but that's a much larger patch.  Is there a reason we don't use it?

Not really.

>   - To make it truly silent, I had to change conf_write() to accept an
>     additional arg.  The alternative is to not have conf_write spit out
>     any information when it writes a file.  Personally, I don't see the need
>     for it to spit out information, but I figured I'd take the more cautious
>     route.  If folks don't care, I can update this patch to remove it.

I rather want to keep this print. The .config is already only written, 
when it has to be in this mode and then I also want to be notified about 
it.

>   - We seem to switch between using _() and not using it for strings; I'm
>     assuming that we don't actually care about i18n in conf.c, and that the
>     _() stuff was just copied from elsewhere.  If that's not the case, I
>     can update the patch to wrap strings properly.

I try to keep this uptodate, but I don't really check for this.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/