public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frans Pop <elendil@planet.nl>
To: paulmck@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, zippel@linux-m68k.org,
	mingo@elte.hu, akpm@linux-foundation.org,
	torvalds@linux-foundation.org, geert@linux-m68k.org,
	cloos@jhcloos.com
Subject: Re: [PATCH] v3 kconfig: place git SHA1 in .config output if in SCM
Date: Fri, 5 Mar 2010 18:18:08 +0100	[thread overview]
Message-ID: <201003051818.10486.elendil@planet.nl> (raw)
In-Reply-To: <20100305052014.GA6869@linux.vnet.ibm.com>

On Friday 05 March 2010, Paul E. McKenney wrote:
> But let's work out what the error strategy should be.  The below are my
> initial guesses, I of course must defer to those more familiar with
> kbuild and kconfig than am I.

That's not me either :-)
I see you've not CCed linux-kbuild@vger.k.o so far. Suggest you add them 
with the next version.

> 1.	Oddball SCM conditions should not cause the build to fail.
> 	"Arrrgh!!!  What dot-file do I need to remove in order for
> 	my builds to start succeeding???"

Agreed.

> 2.	Errors should leave some hint in the .config file, rather
> 	than simply mysteriously omitting the version/dirty information.

I don't see why this should be treated any different than 
CONFIG_LOCALVERSION_AUTO. Either setlocalversion returns something (on 
stdout) and you use it, or it returns nothing and you don't.

With CONFIG_LOCALVERSION_AUTO errors get ignored (tested by adding 'exit 1' 
early in the script) and output to stderr simply gets displayed (without 
any real identification where it comes from).

If users expect the SCM version info to be there and it isn't, they will 
investigate.

> 4.      Should the splat in the .config file identify the file and
>         line number?  For example: "-error: scripts/confdata.c:nnnn"

IMHO definitely not. I think you're over-designing this. It's not really 
core functionality. My viewpoint is simple: a version string should 
contain version info, and nothing else.

> After this is done, I am going to return to something easier to
> understand, like the Linux kernel's RCU implementation.  ;-)

:-)

  reply	other threads:[~2010-03-05 17:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-05  2:54 [PATCH] v3 kconfig: place git SHA1 in .config output if in SCM Paul E. McKenney
2010-03-05  3:43 ` Frans Pop
2010-03-05  5:20   ` Paul E. McKenney
2010-03-05 17:18     ` Frans Pop [this message]
2010-03-05 20:10       ` Paul E. McKenney
2010-03-05 20:31         ` Frans Pop
2010-03-05 20:49           ` Paul E. McKenney
2010-03-05  6:10 ` Mike Galbraith
2010-03-05 12:57   ` Paul E. McKenney

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=201003051818.10486.elendil@planet.nl \
    --to=elendil@planet.nl \
    --cc=akpm@linux-foundation.org \
    --cc=cloos@jhcloos.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox