linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Christopher Li <sparse@chrisli.org>
Cc: Sparse Mailing-list <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH 5/5] Add a --version option to sparse
Date: Fri, 24 Jul 2009 20:30:58 +0100	[thread overview]
Message-ID: <4A6A0BF2.7080509@ramsay1.demon.co.uk> (raw)
In-Reply-To: <70318cbf0907211757w1e0e3436hcc8b679c6de60804@mail.gmail.com>

Christopher Li wrote:
> I don't mind sparse has a version number. Some thing like 4.2.0 etc.
> I would rather not mix that version number with the git commit hash.

The commit hash is only part of the version number string when you
build in a git repo and your HEAD does not reference a release
commit (as indicated by a tag object on this commit).

Note that the "dist" make target already uses 'git describe' to check
that the release tag and VERSION makefile variable agree.

$ git checkout master
$ git describe
0.4.1-99-g37f041a
$ git checkout 0.4.1
Note: moving to '0.4.1' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at a02aeb3... Makefile: VERSION=0.4.1
$ git describe
0.4.1
$ 

[Note that I don't check for locally modified files and add "-dirty"
to the version string like git does; that is partly what I meant by
"minimal implementation"]

> The git commit hash has very limited usage. I think just print it as
> part of the generic verbose printing is good enough. Add the printing in
> handle_switch_v_finalize() so other executable can get it as well.
> 

Hmm, Oops! Now I remember... ahem *blush*, I had intended to modify
this patch before publishing it. (As I said before, this is quite an
old patch; I had a TODO to fix it up).

However, the fixup I have in mind involves moving most of the handling
of the --version option out of the library and into the sparse executable.
(i.e. more or less the opposite of what you suggest above for -v ;-) ).

My intent with this patch was to provide sparse (the program) with a
version number; *not* the sparse library, which is a separate issue.
(If a library version number is implemented, then the sparse program
version number *could* be the same number, of course). I did not
consider the other example programs built with sparse, but I suppose
they could all share the same version number if necessary.

However, you would not want sparse (the library) to force *all*
applications built with the library to handle the --version option
by printing the sparse (the program) version string and exiting!

So, the library should just set a version_option seen flag and let
the application process this flag itself.

Hmm, I don't have time tonight to re-write the patch, but I will
send a new version soon.

ATB,
Ramsay Jones


  reply	other threads:[~2009-07-24 19:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-18 21:06 [PATCH 5/5] Add a --version option to sparse Ramsay Jones
2009-07-22  0:57 ` Christopher Li
2009-07-24 19:30   ` Ramsay Jones [this message]
2009-07-25 19:34     ` Christopher Li
2009-07-28 17:46       ` Ramsay Jones

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=4A6A0BF2.7080509@ramsay1.demon.co.uk \
    --to=ramsay@ramsay1.demon.co.uk \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.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;
as well as URLs for NNTP newsgroup(s).