From: Andres Salomon <dilinger@queued.net>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: kbuild-devel@lists.sourceforge.net, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: UNS: Re: [PATCH] kconfig: add *_silentdefconfig feature for config targets
Date: Tue, 21 Aug 2007 11:41:29 -0400 [thread overview]
Message-ID: <20070821114129.fe2737b4.dilinger@queued.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0708211717180.1817@scrub.home>
On Tue, 21 Aug 2007 17:29:36 +0200 (CEST)
Roman Zippel <zippel@linux-m68k.org> wrote:
> 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.
>
As would I; however, that requires using getopt() (or equivalent). I wasn't
sure if there was some opposition to this..
Of course, we'll still need some way from the makefile to call it. I take
it you're not opposed to 'make foo_silentdefconfig'?
> > 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.
>
Cool, I'll submit a patch that does this.
> > - 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.
>
I'm not sure I follow; should I use _(), or no?
> bye, Roman
--
Andres Salomon <dilinger@queued.net>
next prev parent reply other threads:[~2007-08-21 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-21 0:40 [PATCH] kconfig: add *_silentdefconfig feature for config targets Andres Salomon
2007-08-21 15:29 ` Roman Zippel
2007-08-21 15:41 ` Andres Salomon [this message]
2007-08-21 16:21 ` UNS: " Roman Zippel
2007-10-22 19:00 ` Andres Salomon
2007-08-22 8:07 ` [kbuild-devel] " Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070821114129.fe2737b4.dilinger@queued.net \
--to=dilinger@queued.net \
--cc=akpm@linux-foundation.org \
--cc=kbuild-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.