diff options
Diffstat (limited to 'docs/devel')
| -rw-r--r-- | docs/devel/build-system.rst | 115 | ||||
| -rw-r--r-- | docs/devel/qapi-code-gen.txt | 2 |
2 files changed, 20 insertions, 97 deletions
diff --git a/docs/devel/build-system.rst b/docs/devel/build-system.rst index 0c09fb9a54..08e85c69e1 100644 --- a/docs/devel/build-system.rst +++ b/docs/devel/build-system.rst @@ -125,27 +125,27 @@ developers in checking for system features: `compile_object $CFLAGS` Attempt to compile a test program with the system C compiler using $CFLAGS. The test program must have been previously written to a file - called $TMPC. + called $TMPC. The replacement in Meson is the compiler object `cc`, + which has methods such as `cc.compiles()`, + `cc.check_header()`, `cc.has_function()`. `compile_prog $CFLAGS $LDFLAGS` Attempt to compile a test program with the system C compiler using $CFLAGS and link it with the system linker using $LDFLAGS. The test program must have been previously written to a file called $TMPC. + The replacement in Meson is `cc.find_library()` and `cc.links()`. `has $COMMAND` Determine if $COMMAND exists in the current environment, either as a - shell builtin, or executable binary, returning 0 on success. - -`path_of $COMMAND` - Return the fully qualified path of $COMMAND, printing it to stdout, - and returning 0 on success. + shell builtin, or executable binary, returning 0 on success. The + replacement in Meson is `find_program()`. `check_define $NAME` Determine if the macro $NAME is defined by the system C compiler `check_include $NAME` Determine if the include $NAME file is available to the system C - compiler + compiler. The replacement in Meson is `cc.has_header()`. `write_c_skeleton` Write a minimal C program main() function to the temporary file @@ -179,7 +179,7 @@ process for: - Userspace emulators - qemu-$ARCH - - Some (but not all) unit tests + - Unit tests 2) documentation @@ -204,8 +204,9 @@ are then turned into static libraries as follows:: chardev = declare_dependency(link_whole: libchardev) -The special `.fa` suffix is needed as long as unit tests are built with -the older Makefile infrastructure, and will go away later. +As of Meson 0.55.1, the special `.fa` suffix should be used for everything +that is used with `link_whole`, to ensure that the link flags are placed +correctly in the command line. Files linked into emulator targets there can be split into two distinct groups of files, those which are independent of the QEMU emulation target and @@ -221,7 +222,8 @@ only in system emulators, `user_ss` only in user-mode emulators. In the target-dependent set lives CPU emulation, device emulation and much glue code. This sometimes also has to be compiled multiple times, -once for each target being built. +once for each target being built. Target-dependent files are included +in the `specific_ss` sourceset. All binaries link with a static library `libqemuutil.a`, which is then linked to all the binaries. `libqemuutil.a` is built from several @@ -300,84 +302,9 @@ The resulting build system is largely non-recursive in nature, in contrast to common practices seen with automake. Tests are also ran by the Makefile with the traditional `make check` -phony target. Meson test suites such as `unit` can be ran with `make -check-unit` too. It is also possible to run tests defined in meson.build -with `meson test`. - -The following text is only relevant for unit tests which still have to -be converted to Meson. - -All binaries should link to `libqemuutil.a`, e.g.: - - qemu-img$(EXESUF): qemu-img.o ..snip.. libqemuutil.a - -On Windows, all binaries have the suffix `.exe`, so all Makefile rules -which create binaries must include the $(EXESUF) variable on the binary -name. e.g. - - qemu-img$(EXESUF): qemu-img.o ..snip.. - -This expands to `.exe` on Windows, or an empty string on other platforms. - -Variable naming ---------------- - -The QEMU convention is to define variables to list different groups of -object files. These are named with the convention $PREFIX-obj-y. The -Meson `chardev` variable in the previous example corresponds to a -variable 'chardev-obj-y'. - -Likewise, tests that are executed by `make check-unit` are grouped into -a variable check-unit-y, like this: - - check-unit-y += tests/test-visitor-serialization$(EXESUF) - check-unit-y += tests/test-iov$(EXESUF) - check-unit-y += tests/test-bitmap$(EXESUF) - -When a test or object file which needs to be conditionally built based -on some characteristic of the host system, the configure script will -define a variable for the conditional. For example, on Windows it will -define $(CONFIG_POSIX) with a value of 'n' and $(CONFIG_WIN32) with a -value of 'y'. It is now possible to use the config variables when -listing object files. For example, - - check-unit-$(CONFIG_POSIX) += tests/test-vmstate$(EXESUF) - -On Windows this expands to - - check-unit-n += tests/vmstate.exe - -Since the `check-unit` target only runs tests included in `$(check-unit-y)`, -POSIX specific tests listed in `$(util-obj-n)` are ignored on the Windows -platform builds. - - -CFLAGS / LDFLAGS / LIBS handling --------------------------------- - -There are many different binaries being built with differing purposes, -and some of them might even be 3rd party libraries pulled in via git -submodules. As such the use of the global CFLAGS variable is generally -avoided in QEMU, since it would apply to too many build targets. - -Flags that are needed by any QEMU code (i.e. everything *except* GIT -submodule projects) are put in $(QEMU_CFLAGS) variable. For linker -flags the $(LIBS) variable is sometimes used, but a couple of more -targeted variables are preferred. - -In addition to these variables, it is possible to provide cflags and -libs against individual source code files, by defining variables of the -form $FILENAME-cflags and $FILENAME-libs. For example, the test -test-crypto-tlscredsx509 needs to link to the libtasn1 library, -so tests/Makefile.include defines some variables: - - tests/crypto-tls-x509-helpers.o-cflags := $(TASN1_CFLAGS) - tests/crypto-tls-x509-helpers.o-libs := $(TASN1_LIBS) - -The scope is a little different between the two variables. The libs get -used when linking any target binary that includes the curl.o object -file, while the cflags get used when compiling the curl.c file only. - +phony target, while benchmarks are run with `make bench`. Meson test +suites such as `unit` can be ran with `make check-unit` too. It is also +possible to run tests defined in meson.build with `meson test`. Important files for the build system ==================================== @@ -401,15 +328,9 @@ number of dynamically created files listed later. executables. Build rules for various subdirectories are included in other meson.build files spread throughout the QEMU source tree. -`rules.mak` - This file provides the generic helper rules for invoking build tools, in - particular the compiler and linker. - `tests/Makefile.include` - Rules for building the unit tests. This file is included directly by the - top level Makefile, so anything defined in this file will influence the - entire build system. Care needs to be taken when writing rules for tests - to ensure they only apply to the unit test execution / build. + Rules for external test harnesses. These include the TCG tests, + `qemu-iotests` and the Avocado-based acceptance tests. `tests/docker/Makefile.include` Rules for Docker tests. Like tests/Makefile, this file is included diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt index f3e7ced212..9eede44350 100644 --- a/docs/devel/qapi-code-gen.txt +++ b/docs/devel/qapi-code-gen.txt @@ -835,6 +835,8 @@ Double the '=' for a subsection title: # == Subsection title +Both are only permitted in free-form documentation. + '|' denotes examples: # | Text of the example, may span |