qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: mdroth <mdroth@linux.vnet.ibm.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: akong@redhat.com, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 00/11] qapi: add support for lists of native types
Date: Fri, 17 May 2013 15:06:12 -0500	[thread overview]
Message-ID: <20130517200612.GE2441@vm> (raw)
In-Reply-To: <5194B726.6050201@redhat.com>

On Thu, May 16, 2013 at 12:38:30PM +0200, Laszlo Ersek wrote:
> On 05/15/13 21:13, mdroth wrote:
> > On Wed, May 15, 2013 at 02:05:58PM -0400, Luiz Capitulino wrote:
> >> On Wed, 15 May 2013 12:42:24 -0500
> >> mdroth <mdroth@linux.vnet.ibm.com> wrote:
> 
> >>> The only way I've managed to reproduce this is by having a stale
> >>> qapi-types.h hanging around in $SRC_DIR while i'm building in a
> >>> different $BUILD_DIR. Can you confirm that's not what's happening here?
> >>
> >> Yes, it was :( I had an old qapi-types.h in $SRC_DIR, but was building
> >> in a different $BUILD_DIR. I am really sorry for having wasted your time
> >> on this.
> >>
> >> I've applied this series to qmp-next branch, but I have no idea how I ended
> >> up with a qapi-types.h file in $SRC_DIR. I have an alias to build qemu that
> >> I use for several months now...
> >>
> > 
> > No problem, only thought to check that scenario because it happens to me
> > all the time :)
> 
> Side question: what's a common use case for a separate $BUILD_DIR? I
> just use "git clean -fdx" in $SRC_DIR instead of "make clean". The need
> to reconfigure (and to regenerate my tags file from scratch) is a small
> price to pay for the peace of mind.

I also do it for peace of mind, but I'm not particularly disciplined about
logging all my changes/new files into git as i go, so it's nice to be able to
do a clean build even when my $SRC_DIR is littered with abandoned
code/files/etc by simply wiping out the build dir.

I also have a number of situations where the resulting builds need to
be kept around for a while. For example I have build directories for
v1.1->v1.5 that I keep around for migration testing, other builds
for general usage, and a multitude of temp builds i might create to
compare upstream against a test/stable/development build. I could
use `make install` with an install prefix for this but for me it's quicker
to just use the binaries within the build directory.

Wasn't aware of `git clean` though, always just tried to make
due with `git reset --hard` + rm but that can get tedious at times.

> 
> Thanks
> Laszlo
> 

      parent reply	other threads:[~2013-05-17 20:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-10 22:45 [Qemu-devel] [PATCH v3 00/11] qapi: add support for lists of native types Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 01/11] qapi: qapi-types.py, native list support Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 02/11] qapi: qapi-visit.py, fix list handling for union types Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 03/11] qapi: qapi-visit.py, native list support Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 04/11] qapi: enable generation of native list code Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 05/11] qapi: fix leak in unit tests Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 06/11] json-parser: fix handling of large whole number values Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 07/11] qapi: add QMP input test for large integers Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 08/11] qapi: fix visitor serialization tests for numbers/doubles Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 09/11] qapi: add native list coverage for visitor serialization tests Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 10/11] qapi: add native list coverage for QMP output visitor tests Michael Roth
2013-05-10 22:46 ` [Qemu-devel] [PATCH 11/11] qapi: add native list coverage for QMP input " Michael Roth
2013-05-13  6:54 ` [Qemu-devel] [PATCH v3 00/11] qapi: add support for lists of native types Laszlo Ersek
2013-05-13 13:52 ` Amos Kong
2013-05-15 13:17 ` Luiz Capitulino
2013-05-15 14:32   ` mdroth
2013-05-15 15:04     ` Luiz Capitulino
2013-05-15 17:42       ` mdroth
2013-05-15 18:05         ` Luiz Capitulino
2013-05-15 19:13           ` mdroth
2013-05-16 10:38             ` Laszlo Ersek
2013-05-16 10:45               ` Peter Maydell
2013-05-17 20:06               ` mdroth [this message]

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=20130517200612.GE2441@vm \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=akong@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=lersek@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).