From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeSIa-0001nW-23 for qemu-devel@nongnu.org; Tue, 22 Sep 2015 14:28:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeSIW-0005jp-Sz for qemu-devel@nongnu.org; Tue, 22 Sep 2015 14:28:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeSIW-0005jS-Ns for qemu-devel@nongnu.org; Tue, 22 Sep 2015 14:28:12 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 5CD0C2CD80B for ; Tue, 22 Sep 2015 18:28:12 +0000 (UTC) References: <1442939759-9862-1-git-send-email-berrange@redhat.com> <560199E7.6020401@redhat.com> From: Laszlo Ersek Message-ID: <56019DB9.3020804@redhat.com> Date: Tue, 22 Sep 2015 20:28:09 +0200 MIME-Version: 1.0 In-Reply-To: <560199E7.6020401@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] docs: describe the QEMU build system structure / design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: qemu-devel@nongnu.org meta review of your review: On 09/22/15 20:11, John Snow wrote: > Reviewed from an en_US perspective, though I left alone things that are > clearly regional (e.g. 'behaviour' vs 'behavior') > > On 09/22/2015 12:35 PM, Daniel P. Berrange wrote: >> + - Add information to the help output message to report on the new >> + feature flag. >> + > > Remove period, or add to the other list items for consistency. My > personal preference is to use the period for any sentences with proper > grammatical structure, omitting it for simple list items. Then: >> +which create binaries must include the $(EXESUF) variable on the binary >> +name. eg > > 'e.g.' here and everywhere subsequent. Self-contradiction found!!!1111eleven :) Honestly I'm surprised (or not) how many typos you've found that I blissfully slid over. >> +Each system/userspace emulation target needs to have a slightly >> +different set of make rules / variables. Thus, make will be recursively >> +invoked for each of the emulation targets. >> + >> +The recursive invokation will end up processing the toplevel > > invocation again. Self-contradictory period again! :) > Thanks for writing this! Yes! > Pretending to be Eric, Yes. :) Cheers Laszlo