All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.cz>
To: David Rientjes <rientjes@google.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [patch] kbuild: improve version string logic
Date: Tue, 05 Jan 2010 14:59:11 +0100	[thread overview]
Message-ID: <4B4345AF.9040600@suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.00.1001041330230.26148@chino.kir.corp.google.com>

On 4.1.2010 22:31, David Rientjes wrote:
> The LOCALVERSION= string passed to "make" will now always be appended to
> the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
> whether CONFIG_LOCALVERSION_AUTO is set or not.  This allows users to
> uniquely identify their kernel builds with a string.
> 
> scripts/setlocalversion will now always be called to determine whether
> the repository is beyond a tagged (release) commit.  When at a tagged
> commit, this script will now suppress all output.
> 
> If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by 
> setlocalversion (or .scmversion) is appended to the kernel version, if it 
> exists.  When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
> to the kernel version to represent that the kernel has been revised since
> the last release unless "make LOCALVERSION=" was used to uniquely identify
> the build.
> 
> The end result is this:
> 
>  - when LOCALVERSION= is passed to "make", it is appended to the kernel
>    version,
> 
>  - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
>    appended if the respository has been revised beyond a tagged commit,
>    and
> 
>  - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the 
>    repository has been revised beyond a tagged commit and LOCALVERSION=
>    was not passed to "make".

I've read the thread from last October where this was discussed
(http://thread.gmane.org/gmane.linux.kernel/897768/focus=898233). I'm
not entirely sure if all people will be happy about the plus sign that
can't be turned off, but from the thread I got the impression that the
plus sign is wanted, so let's add this to linux-next now, so that people
doing automated builds can adjust their scripts if needed. Just in case:
Stephen, won't this break your linux-next scripts in any way? The final
build won't change, because of the next-YYYYMMDD tag, but the builds in
between will have the '+' appended to their version.


Two small comments are below.

> Examples:
> 
> With CONFIG_LOCALVERSION_AUTO: "make" results in
> v2.6.32-rc4-00149-ga3ccf63.  If there are uncommited changes to the
> respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty.  If
> "make LOCALVERSION=kbuild" were used, it results in
> v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.
> 
> Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
> unless the repository is at the Linux v2.6.32-rc4 commit (in which
> case the version would be v2.6.32-rc4).  If "make LOCALVERSION=kbuild"
> were used, it results in v2.6.32-rc4-kbuild.
> 
> Also renames variables such as localver-auto and _localver-auto to more 
> accurately describe what they represent: localver-extra and
> scm-identifier, respectively.
> 
> Acked-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
>  Makefile                |   43 +++++++++++++++++++++++++++----------------
>  scripts/setlocalversion |    3 ++-
>  2 files changed, 29 insertions(+), 17 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
>  #	  $(localver)
>  #	    localversion*		(files without backups, containing '~')
>  #	    $(CONFIG_LOCALVERSION)	(from kernel config setting)
> -#	  $(localver-auto)		(only if CONFIG_LOCALVERSION_AUTO is set)
> -#	    ./scripts/setlocalversion	(SCM tag, if one exists)
> -#	    $(LOCALVERSION)		(from make command line if provided)
> +#	    $(LOCALVERSION)		(from make command line, if provided)

$(LOCALVERSION) is no longer part of $(localver), it should be indented
at the same level.


> +#	  $(localver-extra)
> +#	    $(scm-identifier)		(unique SCM tag, if one exists)
> +#	      ./scripts/setlocalversion	(only with CONFIG_LOCALVERSION_AUTO)
> +#	      .scmversion		(only with CONFIG_LOCALVERSION_AUTO)
> +#	    +				(only without CONFIG_LOCALVERSION_AUTO
> +#					 and without LOCALVERSION= and 
> +#					 repository is at non-tagged commit)
>  #
> -#  Note how the final $(localver-auto) string is included *only* if the
> -# kernel config option CONFIG_LOCALVERSION_AUTO is selected.  Also, at the
> -# moment, only git is supported but other SCMs can edit the script
> -# scripts/setlocalversion and add the appropriate checks as needed.
> +# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
> +# been revised beyond a tagged commit, `+' is appended to the version string
> +# when not overridden by using "make LOCALVERSION=".  This indicates that the
> +# kernel is not a vanilla release version and has been modified.
>  
>  pattern = ".*/localversion[^~]*"
>  string  = $(shell cat /dev/null \
> @@ -914,26 +919,32 @@ string  = $(shell cat /dev/null \
>  localver = $(subst $(space),, $(string) \
>  			      $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
>  
> -# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
> -# and if the SCM is know a tag from the SCM is appended.
> -# The appended tag is determined by the SCM used.
> +# scripts/setlocalversion is called to create a unique identifier if the source
> +# is managed by a known SCM and the repository has been revised since the last
> +# tagged (release) commit.  The format of the identifier is determined by the
> +# SCM's implementation.
>  #
>  # .scmversion is used when generating rpm packages so we do not loose
>  # the version information from the SCM when we do the build of the kernel
>  # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
>  ifeq ($(wildcard .scmversion),)
> -        _localver-auto = $(shell $(CONFIG_SHELL) \
> +        scm-identifier = $(shell $(CONFIG_SHELL) \
>                           $(srctree)/scripts/setlocalversion $(srctree))
>  else
> -        _localver-auto = $(shell cat .scmversion 2> /dev/null)
> +        scm-identifier = $(shell cat .scmversion 2> /dev/null)
>  endif
>  
> -	localver-auto  = $(LOCALVERSION)$(_localver-auto)
> +ifdef CONFIG_LOCALVERSION_AUTO
> +	localver-extra = $(scm-identifier)
> +else
> +	ifneq ($scm-identifier,)
> +		ifeq ($(LOCALVERSION),)
> +			localver-extra = +
> +		endif
> +	endif
>  endif
>  
> -localver-full = $(localver)$(localver-auto)
> +localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
>  
>  # Store (new) KERNELRELASE string in include/config/kernel.release
>  kernelrelease = $(KERNELVERSION)$(localver-full)
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
>  		# If we are past a tagged commit (like "v2.6.30-rc5-302-g72357d5"),
>  		# we pretty print it.
>  		if atag="`git describe 2>/dev/null`"; then
> -			echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
> +			echo "$atag" | awk -F- 'int($(NF-1)) > 0	\
> +					{printf("-%05d-%s", $(NF-1),$(NF))}'
>
>  		# If we don't have a tag at all we print -g{commitish}.
>  		else

Why is this needed? There is

	# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore it,
	# because this version is defined in the top level Makefile.
	if [ -z "`git describe --exact-match 2>/dev/null`" ]; then

a few lines above and even without your patch ./scripts/setlocalversion
returns nothing when HEAD is tagged. Do you have an old git version that
doesn't undestand --exact-match? In that case, the if around this should
be removed.

thanks,
Michal

  reply	other threads:[~2010-01-05 13:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-04 21:31 [patch] kbuild: improve version string logic David Rientjes
2010-01-05 13:59 ` Michal Marek [this message]
2010-01-05 14:11   ` Stephen Rothwell
2010-01-13 21:01   ` David Rientjes
2010-01-16  6:37     ` Ingo Molnar
2010-01-16  7:34       ` Stephen Rothwell
2010-01-16  9:26         ` Ingo Molnar
2010-01-18  9:40           ` Michal Marek
2010-01-18 10:45             ` David Rientjes
2010-01-18 11:15               ` Michal Marek
2010-01-18 15:53                 ` Jiri Kosina
  -- strict thread matches above, loose matches on Subject: below --
2009-10-05  0:44 Linux 2.6.32-rc3 Linus Torvalds
2009-10-06  1:57 ` Len Brown
2009-10-06  2:51   ` Dirk Hohndel
2009-10-06 14:18     ` Linus Torvalds
2009-10-06 14:44       ` Ingo Molnar
2009-10-06 15:24         ` Linus Torvalds
2009-10-06 15:36           ` Ingo Molnar
2009-10-06 15:51             ` Linus Torvalds
2009-10-06 16:31               ` Linus Torvalds
2009-10-06 17:35                 ` [patch] kbuild: Improve version string logic Ingo Molnar
2009-10-06 18:37                   ` Johannes Berg
2009-10-06 18:49                     ` Ingo Molnar
2009-10-06 18:55                       ` Johannes Berg
2009-10-06 19:03                     ` Theodore Tso
2009-10-06 19:45                     ` Frans Pop
2009-10-06 19:48                       ` Johannes Berg
2009-10-06 20:25                         ` Frans Pop
2009-10-07  2:43                   ` David Rientjes

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=4B4345AF.9040600@suse.cz \
    --to=mmarek@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rientjes@google.com \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.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.