From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UchAg-0000BF-4a for qemu-devel@nongnu.org; Wed, 15 May 2013 15:15:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UchAe-0002sV-EP for qemu-devel@nongnu.org; Wed, 15 May 2013 15:15:30 -0400 Received: from mail-ia0-x22f.google.com ([2607:f8b0:4001:c02::22f]:47049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UchAe-0002sJ-7x for qemu-devel@nongnu.org; Wed, 15 May 2013 15:15:28 -0400 Received: by mail-ia0-f175.google.com with SMTP id m10so2542592iam.34 for ; Wed, 15 May 2013 12:15:27 -0700 (PDT) Sender: fluxion Date: Wed, 15 May 2013 14:13:09 -0500 From: mdroth Message-ID: <20130515191309.GB23880@vm> References: <1368225970-28506-1-git-send-email-mdroth@linux.vnet.ibm.com> <20130515091746.68ee3f4d@redhat.com> <20130515143237.GM13213@vm> <20130515110427.5b8b4fbf@redhat.com> <20130515174224.GN13213@vm> <20130515140558.7687e36f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130515140558.7687e36f@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 00/11] qapi: add support for lists of native types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: akong@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org On Wed, May 15, 2013 at 02:05:58PM -0400, Luiz Capitulino wrote: > On Wed, 15 May 2013 12:42:24 -0500 > mdroth wrote: > > > On Wed, May 15, 2013 at 11:04:27AM -0400, Luiz Capitulino wrote: > > > On Wed, 15 May 2013 09:32:37 -0500 > > > mdroth wrote: > > > > > > > On Wed, May 15, 2013 at 09:17:46AM -0400, Luiz Capitulino wrote: > > > > > On Fri, 10 May 2013 17:45:59 -0500 > > > > > Michael Roth wrote: > > > > > > > > > > > These patches apply on top of qemu.git master, and can also be obtained from: > > > > > > git://github.com/mdroth/qemu.git qapi-native-lists > > > > > > > > > > > > Sending this now since a number of series have popped up in the past that > > > > > > wanted this, and Amos has some pending patches (query-mac-tables) that rely > > > > > > on this as well. > > > > > > > > > > > > These patches add support for specifying lists of native qapi types > > > > > > (int/bool/str/number/int8/uint8/etc) like so: > > > > > > > > > > > > { 'type': 'foo', > > > > > > 'data': { 'bar': ['int'] }} > > > > > > > > > > > > for a 'bar' field that is a list of type 'int', > > > > > > > > > > > > { 'type': 'foo2', > > > > > > 'data': { 'bar2': ['str'] }} > > > > > > > > > > > > for a 'bar2' field that is a list of type 'str', and so on. > > > > > > > > > > > > This uses linked list types for the native C representations, just as we do > > > > > > for complex schema-defined types. In the future we may add schema annotations > > > > > > of some sort to specify a more natural/efficient array type for the C > > > > > > representations, but this should serve the majority of uses-cases for now. > > > > > > > > > > I'm getting a build breakage when building all targets: > > > > > > > > Hmm, tested all target builds and didn't/don't see any issues. Is this a > > > > clean build? Can you confirm whether or not int8List/etc are declared in > > > > qapi-types.h in your current build dir? > > > > > > Yes, it's a clean build and yes, the int?List declarations are being generated. > > > Tested a little bit more and this also happens with make -j1 and when > > > building only one target (x86_64 in my case). > > > > 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 :)