From: Laszlo Ersek <lersek@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, Kashyap Chamarthy <kchamart@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] configure: save git working tree information in "pkgversion"
Date: Tue, 31 May 2016 19:01:58 +0200 [thread overview]
Message-ID: <8d55914d-e57c-43e3-5319-28db331de5f8@redhat.com> (raw)
In-Reply-To: <20160531154346.GB21628@redhat.com>
On 05/31/16 17:43, Daniel P. Berrange wrote:
> On Tue, May 31, 2016 at 05:40:38PM +0200, Laszlo Ersek wrote:
>> On 05/31/16 17:14, Daniel P. Berrange wrote:
>>> On Tue, May 31, 2016 at 05:04:04PM +0200, Laszlo Ersek wrote:
>>>> When building QEMU from a git working tree (either in-tree or
>>>> out-of-tree), it is useful to capture the working tree status in the QEMU
>>>> binary, for the "-version" option to report.
>>>>
>>>> Daniel suggested using the "pkgversion" variable (tied to the
>>>> "--with-pkgversion" option) of the configure script for this. Downstream
>>>> packagers of QEMU already use this option for customizing their builds,
>>>> plus libvirtd captures "pkgversion" (with the "-version" option) in
>>>> "/var/log/libvirt/qemu/$GUEST.log", whenever a guest is started.
>>>>
>>>> The information we include in "pkgversion" is the output of git-describe,
>>>> with a plus sign (+) appended if there are staged or unstaged changes to
>>>> tracked files, at the time of "configure" being executed.
>>>>
>>>> The content of "pkgversion" is not changed when "--with-pkgversion" is
>>>> used on the command line.
>>>>
>>>> Cc: "Daniel P. Berrange" <berrange@redhat.com>
>>>> Cc: Kashyap Chamarthy <kchamart@redhat.com>
>>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>>> ---
>>>> configure | 38 ++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 38 insertions(+)
>>>>
>>>> diff --git a/configure b/configure
>>>> index b5aab7257b33..20a7ec5cc0fd 100755
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -4255,6 +4255,44 @@ if have_backend "dtrace"; then
>>>> fi
>>>>
>>>> ##########################################
>>>> +# save git working tree information in pkgversion
>>>> +
>>>> +# If pkgversion has not been set to a non-empty string, fetch the output of
>>>> +# "git describe" into it. If the working tree is unclean (there are staged or
>>>> +# unstaged changes in tracked files), then append a plus sign.
>>>> +#
>>>> +# If we're not building from a git working tree, then pkgversion is not
>>>> +# changed. Otherwise, git errors are fatal.
>>>> +
>>>> +if test -z "$pkgversion" && test -d "$source_path/.git"; then
>>>> + pkgversion=$(
>>>> + export GIT_DIR=$source_path/.git
>>>> + export GIT_WORK_TREE=$source_path
>>>> +
>>>> + git_desc=$(git describe)
>>>> + git_exit=$?
>>>> + if test $git_exit -ne 0; then
>>>> + exit $git_exit
>>>> + fi
>>>> +
>>>> + git_changes=
>>>> + for git_diff_option in "" --staged; do
>>>> + git diff $git_diff_option --quiet
>>>> + git_exit=$?
>>>> + case $git_exit in
>>>> + (0) ;;
>>>> + (1) git_changes=+
>>>> + ;;
>>>> + (*) exit $git_exit
>>>> + ;;
>>>> + esac
>>>> + done
>>>
>>> An alternative to this would be to jus use
>>>
>>> "git describe --dirty"
>>>
>>> which appends "--dirty" to its output if working tre has uncommitted
>>> changes.
>>
>> Good idea!
>>
>>> Not sure if the --dirty flag is a recent option or whether we can just
>>> assume it always exists.
>>
>> Grepping git's Documentation/RelNotes/ directory, I find:
>> - in "1.6.6.txt": the introduction of --dirty
>> - in "1.7.6.4.txt": an apparently important bugfix for --dirty
>>
>> Version 1.7.6.4 of git was tagged on Sep 23 2011.
>>
>> Does this information help in deciding if we can use --dirty?
>
> 5 years old sounds new enough for my liking :-)
>
> I guess we could use --dirty and catch the non-zero exit code and just
> re-try without --dirty.
But, if we can't use --dirty, I should probably use the plus-sign
fallback (we need *something* to mark a dirty state).
In which case however, shouldn't we just go with the current patch,
which doesn't care about --dirty at all? Otherwise, some build hosts
will append "-dirty", and others will append "+".
IMO we should either require --dirty, or go with the current patch.
Thanks
Laszlo
next prev parent reply other threads:[~2016-05-31 17:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 15:04 [Qemu-devel] [PATCH] configure: save git working tree information in "pkgversion" Laszlo Ersek
2016-05-31 15:14 ` Daniel P. Berrange
2016-05-31 15:40 ` Laszlo Ersek
2016-05-31 15:43 ` Daniel P. Berrange
2016-05-31 17:01 ` Laszlo Ersek [this message]
2016-05-31 17:45 ` Eric Blake
2016-05-31 21:16 ` Laszlo Ersek
2016-06-01 8:55 ` Laszlo Ersek
2016-06-01 9:11 ` Fam Zheng
2016-06-01 9:36 ` Kashyap Chamarthy
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=8d55914d-e57c-43e3-5319-28db331de5f8@redhat.com \
--to=lersek@redhat.com \
--cc=berrange@redhat.com \
--cc=kchamart@redhat.com \
--cc=qemu-devel@nongnu.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).