All of lore.kernel.org
 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 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.