From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZemFk-0002C4-Im for qemu-devel@nongnu.org; Wed, 23 Sep 2015 11:46:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZemFg-00025s-Sh for qemu-devel@nongnu.org; Wed, 23 Sep 2015 11:46:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZemFg-00025n-OW for qemu-devel@nongnu.org; Wed, 23 Sep 2015 11:46:36 -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 62C8498C08 for ; Wed, 23 Sep 2015 15:46:36 +0000 (UTC) References: <1443002356-22481-1-git-send-email-berrange@redhat.com> From: Laszlo Ersek Message-ID: <5602C95A.1060705@redhat.com> Date: Wed, 23 Sep 2015 17:46:34 +0200 MIME-Version: 1.0 In-Reply-To: <1443002356-22481-1-git-send-email-berrange@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] docs: describe the QEMU build system structure / design List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: Paolo Bonzini , John Snow I diffed this version against v1. Thank you for addressing my comments too; however I found some newly introduced typos: On 09/23/15 11:59, Daniel P. Berrange wrote: > +The utility code that is used by all binaries is built into a > +static archive called libqemuutil.a, which is then linked to all the > +binaries. In order to provides hooks that are only needed by some of the to provide[] > +binaries, code in libqemuutil.a may depend on other functions that are > +not fully implementd by all QEMU binaries. To deal with this there is a implement[e]d To deal with this[,] > +second library called libqemustub.a which provide dummy stubs for all [,] which provide[s] > +these functions. These will get lazy linked into the binary if the real > +implementation is not present. In this way, the libqemustub.a static > +library can be thought of as a portable implementation of the weak > +symbols concept. All binaries should link to both libqemuutil.a and > +libqemustub.a. e.g. [,] e.g.[:] -- but I don't feel strongly about this :) > + > + qemu-img$(EXESUF): qemu-img.o ..snip.. libqemuutil.a libqemustub.a > + > + > +Windows platform portability > +---------------------------- > + > +On Windows all binaries have a 'exe' suffix, so all the Makefile rules This was "a .exe suffix" before, and Jon commented that you probably pronounced it as "a dot-exe suffix". Now you've removed the dot, but haven't changed "a" into "an". :) > +If there are any rules defined in the Makefile.objs file, they should > +all use $(obj) as a prefix to the target e.g. target[,] e.g.[:] -- not very necessary though > +Dynamically created files > +------------------------- > + > +The following files are generated dynamically by configure in order to > +control the behaviour of the statically defined makefiles. This avoids > +the need for QEMU makefiles to go through any pre-processing as seen > +with autotools, where Makefile.am generates Makefile.in which generates > +Makefile. > + I suggest to insert another empty line here, with consistency for the other entries below. (This is not new in v2, so sorry about pointing it out now.) For the next version (v3): Acked-by: Laszlo Ersek Thanks Laszlo