From: Eric Blake <eblake@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] docs: describe the QEMU build system structure / design
Date: Tue, 22 Sep 2015 12:22:09 -0600 [thread overview]
Message-ID: <56019C51.6050600@redhat.com> (raw)
In-Reply-To: <1442939759-9862-1-git-send-email-berrange@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]
On 09/22/2015 10:35 AM, Daniel P. Berrange wrote:
> Developers who are new to QEMU, or have a background familiarity
> with GNU autotools can have trouble getting their head around the
s/autotools/autotools,/
> home-grown QEMU build system. This document attempts to explain
> the structure / design of the configure script and the various
> Makefile pieces that live across the source tree.
>
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---
> docs/build-system.txt | 493 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 493 insertions(+)
> create mode 100644 docs/build-system.txt
>
> +Stage 1: configure
> +
> +In contrast to autoconf scripts, QEMU's configure is expected to be
> +silent while it is checking for features. It will only display output
> +when an error occurrs, or to show the final feature enablement summary
s/occurrs/occurs/
> +on completion.
> +
> +Adding new checks to the configure script usually comprises the
> +following tasks
> +
> + - Initialize one or more variables with the default feature state.
> +
> + Ideally features should auto-detect whether they are present,
> + so try to avoid hardcoding the initial state to either enabled
> + or disabled, as that forces the user to pass a --{dis,en}able-XXX
> + flag on every invokation of configure
s/invokation/invocation/
> +Stage 2: makefiles
> +==================
> +
> +Although the source code is spread across multiple subdirectories, the
> +build system should be considered largely non-recursive in nature, in
> +contrast to common practices seen with automake. There is some recursive
> +invokation of make, but this is related to the things being built,
> +rather than the source directory structure.
s/invokation/invocation/
Mention that we require GNU make.
> +Module structure
> +----------------
> +
> +There are a number of key outputs of the QEMU build system
> +
> + - Tools - qemu-img, qemu-nbd, qga (guest agent), etc
> + - System emulators - qemu-system-$ARCH
> + - Userspace emulators - qemu-$ARCH
> + - Unit tests
> +
> +The source code is highly modularized, split across many files to
> +facilitate building of all of these components with as little duplicated
> +compilation as possible. There can be considered to be two distinct
> +groups of files, those which are independant of the QEMU emulation
> +target and those which are dependant on the QEMU emulation target.
Throughout this section: s/(in)?dependant/dependent/
> +
> +Statically defined files
> +------------------------
> +The recursive invokation will end up processing the toplevel
s/invokation/invocation/
> +
> +Dynamically created files
> +-------------------------
> +
> +The following files are generated dynamically by configure in order to
> +control the behaviour of the staticaly defined makefiles. This avoids
s/staticaly/statically/
> +
> +It is also used as a dependancy checking mechanism. If make sees that
s/dependancy/dependency/
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2015-09-22 18:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 16:35 [Qemu-devel] [PATCH] docs: describe the QEMU build system structure / design Daniel P. Berrange
2015-09-22 18:11 ` John Snow
2015-09-22 18:28 ` Laszlo Ersek
2015-09-22 18:51 ` Eric Blake
2015-09-22 19:01 ` Laszlo Ersek
2015-09-22 19:47 ` Paolo Bonzini
2015-09-22 18:21 ` Laszlo Ersek
2015-09-22 18:22 ` Eric Blake [this message]
2015-09-23 8:35 ` Daniel P. Berrange
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=56019C51.6050600@redhat.com \
--to=eblake@redhat.com \
--cc=berrange@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.