7 files changed, 36 insertions, 55 deletions
diff --git a/docs/markdown/Getting-meson.md b/docs/markdown/Getting-meson.md
index c01a947..d654ff3 100644
--- a/docs/markdown/Getting-meson.md
+++ b/docs/markdown/Getting-meson.md
@@ -12,7 +12,7 @@ The newest development code can be obtained directly from [Git]
 ## Dependencies
 
 Meson is implemented in Python 3. If your operating system provides a
-package manager, use should install it with that. For platforms that
+package manager, you should install it with that. For platforms that
 don't have a package manager, you need to download it from [Python's
 home page].
 
diff --git a/docs/markdown/Overview.md b/docs/markdown/Overview.md
index 537aa8f..c9acda5 100644
--- a/docs/markdown/Overview.md
+++ b/docs/markdown/Overview.md
@@ -6,7 +6,7 @@ short-description: Overview of the Meson build system
 
 Meson is a build system that is designed to be as user-friendly as possible without sacrificing performance. The main tool for this is a custom language that the user uses to describe the structure of his build. The main design goals of this language has been simplicity, clarity and conciseness. Much inspiration was drawn from the Python programming language, which is considered very readable, even to people who have not programmed in Python before.
 
-Another main idea has been to provide first class support for modern programming tools and best practices. These include features as varied as unit testing, code coverage reporting, precompiled headers and the like. All of these features should be immediately available to any project using Meson. The user should not need to hunt for third party macros or write shell scripts to get these features. They just just work out of the box.
+Another main idea has been to provide first class support for modern programming tools and best practices. These include features as varied as unit testing, code coverage reporting, precompiled headers and the like. All of these features should be immediately available to any project using Meson. The user should not need to hunt for third party macros or write shell scripts to get these features. They should just work out of the box.
 
 This power should not come at the expense of limited usability. Many software builds require unorthodox steps. A common example is that you first need to build a custom tool and then use that tool to generate more source code to build. This functionality needs to be supported and be as easy to use as other parts of the system.
 
diff --git a/docs/markdown/Reference-manual.md b/docs/markdown/Reference-manual.md
index a6dc968..c835f6f 100644
--- a/docs/markdown/Reference-manual.md
+++ b/docs/markdown/Reference-manual.md
@@ -132,7 +132,7 @@ These are all the supported keyword arguments:
 ### custom_target()
 
 ``` meson
-    ctarget custom_target(*name*, ...)
+    customtarget custom_target(*name*, ...)
 ```
 
 Create a custom top level build target. The only positional argument is the name of this target and the keyword arguments are the following.
@@ -158,6 +158,8 @@ The list of strings passed to the `command` keyword argument accept the followin
 - `@OUTDIR@` the full path to the directory where the output(s) must be written
 - `@DEPFILE@` the full path to the dependency file passed to `depfile`
 
+The returned object also has methods that are documented in the [object methods section](#custom-target-object) below.
+
 ### declare_dependency()
 
 ``` meson
@@ -212,7 +214,7 @@ Returns an empty [environment variable object](#environment-object).
 ### executable()
 
 ``` meson
-    exe executable(*exe_name*, *sources*, ...)
+    buildtarget executable(*exe_name*, *sources*, ...)
 ```
 
 Creates a new executable. The first argument specifies its name and the remaining positional arguments define the input files to use. They can be of the following types:
@@ -647,7 +649,7 @@ Defined tests can be run in a backend-agnostic way by calling `mesontest` inside
 ### vcs_tag()
 
 ``` meson
-    ctarget vcs_tag(...)
+    customtarget vcs_tag(...)
 ```
 
 This command detects revision control commit information at build time and places it in the specified output file. This file is guaranteed to be up to date on every build. Keywords are similar to `custom_target`.
@@ -737,18 +739,6 @@ When all compilation is 'native', all the methods return the same values as `bui
 
 Note that while cross-compiling, it simply returns the values defined in the cross-info file. If `target_machine` values are not defined in the cross-info file, `host_machine` values are returned instead.
 
-### `build target` object
-
-A build target is either an [executable](#executable), [shared](#shared_library) or [static library](#static_library).
-
-- `extract_objects()` returns an opaque value representing the generated object files of arguments, usually used to take single object files and link them to unit tests or to compile some source files with custom flags. To use the object file(s) in another build target, use the `objects:` keyword argument.
-
-- `extract_all_objects()` is same as above but returns all object files generated by this target
-
-- `private_dir_include()` returns a opaque value that works like `include_directories` but points to the private directory of this target, usually only needed if an another target needs to access some generated internal headers of this target
-
-- `full_path()` returns a full path pointing to the result target file
-
 ### `compiler` object
 
 This object is returned by [`meson.get_compiler(lang)`](#meson-object). It represents a compiler for a given language and allows you to query its properties. It has the following methods:
@@ -833,14 +823,17 @@ You can also iterate over arrays with the [`foreach` statement](https://github.c
 
 These are objects returned by the [functions listed above](#functions).
 
-### `run result` object
+### `build target` object
 
-This object encapsulates the result of trying to compile and run a sample piece of code with [`compiler.run()`](#compiler-object) or [`run_command()`](#run_command). It has the following methods:
+A build target is either an [executable](#executable), [shared](#shared_library), [static library](#static_library) or [shared module](#shared_module).
 
-- `compiled()` if true, the compilation succeeded, if false it did not and the other methods return unspecified data
-- `returncode()` the return code of executing the compiled binary
-- `stdout()` the standard out produced when the binary was run
-- `stderr()` the standard error produced when the binary was run
+- `extract_objects()` returns an opaque value representing the generated object files of arguments, usually used to take single object files and link them to unit tests or to compile some source files with custom flags. To use the object file(s) in another build target, use the `objects:` keyword argument.
+
+- `extract_all_objects()` is same as above but returns all object files generated by this target
+
+- `private_dir_include()` returns a opaque value that works like `include_directories` but points to the private directory of this target, usually only needed if an another target needs to access some generated internal headers of this target
+
+- `full_path()` returns a full path pointing to the result target file
 
 ### `configuration` data object
 
@@ -854,6 +847,12 @@ This object is returned by [`configuration_data()`](#configuration_data) and enc
 
 They all take the `description` keyword that will be written in the result file. The replacement assumes a file with C syntax. If your generated file is source code in some other language, you probably don't want to add a description field because it most likely will cause a syntax error.
 
+### `custom target` object
+
+This object is returned by [`custom_target`](#custom_target) and contains a target with the following methods:
+
+- `full_path()` returns a full path pointing to the result target file
+
 ### `dependency` object
 
 This object is returned by [`dependency()`](#dependency) and contains an external dependency with the following methods:
@@ -906,3 +905,11 @@ This object is returned by [`subproject()`](#subproject) and is an opaque object
   subproject. This is useful to, for instance, get a [declared
   dependency](#declare_dependency) from the subproject.
 
+### `run result` object
+
+This object encapsulates the result of trying to compile and run a sample piece of code with [`compiler.run()`](#compiler-object) or [`run_command()`](#run_command). It has the following methods:
+
+- `compiled()` if true, the compilation succeeded, if false it did not and the other methods return unspecified data
+- `returncode()` the return code of executing the compiled binary
+- `stdout()` the standard out produced when the binary was run
+- `stderr()` the standard error produced when the binary was run
diff --git a/docs/markdown/Unit-tests.md b/docs/markdown/Unit-tests.md
index 1aa7806..13d66f7 100644
--- a/docs/markdown/Unit-tests.md
+++ b/docs/markdown/Unit-tests.md
@@ -30,7 +30,7 @@ Note how you need to specify multiple values as an array.
 Coverage
 --
 
-If you enable coverage measurements by giving Meson the command line flag `-Db_coverage=true`, you can generate coverage reports. Meson will autodetect what coverage generator tools you have installed and will generate the corresponding targets. These targets are `coverage-xml` and `coverage-text` which are both provided by [Gcovr](https://software.sandia.gov/trac/fast/wiki/gcovr) and `coverage-html`, which requires [Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and [GenHTML](https://linux.die.net/man/1/genhtml).
+If you enable coverage measurements by giving Meson the command line flag `-Db_coverage=true`, you can generate coverage reports. Meson will autodetect what coverage generator tools you have installed and will generate the corresponding targets. These targets are `coverage-xml` and `coverage-text` which are both provided by [Gcovr](http://gcovr.com) and `coverage-html`, which requires [Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and [GenHTML](https://linux.die.net/man/1/genhtml).
 
 The the output of these commands is written to the log directory `meson-logs` in your build directory.
 
diff --git a/docs/markdown/Users.md b/docs/markdown/Users.md
index 574df27..0d24d6b 100644
--- a/docs/markdown/Users.md
+++ b/docs/markdown/Users.md
@@ -9,6 +9,7 @@ If you have a project that uses Meson that you want to add to this list, let us
  - [AQEMU](https://github.com/tobimensch/aqemu), a Qt GUI for QEMU virtual machines, since version 0.9.3
  - [Arduino sample project](https://github.com/jpakkane/mesonarduino)
  - [Emeus](https://github.com/ebassi/emeus), Constraint based layout manager for GTK+
+ - [Frida.re](https://github.com/frida/frida-core), a code tracing framework
  - [GLib](https://github.com/centricular/glib/), cross-platform C library used by GTK+ (not merged yet)
  - [Gnome Builder](https://git.gnome.org/browse/gnome-builder/), an IDE for the Gnome platform
  - [Gnome MPV](https://github.com/gnome-mpv/gnome-mpv), Gnome frontend to the mpv video player
@@ -19,6 +20,7 @@ If you have a project that uses Meson that you want to add to this list, let us
  - [Grilo](https://mail.gnome.org/archives/grilo-list/2017-February/msg00000.html) and [Grilo plugins](https://git.gnome.org/browse/grilo-plugins/commit/?id=ea047c4fb63e90268eb795ed91a09a2be5068a4c), the Grilo multimedia framework
  - [GStreamer](https://cgit.freedesktop.org/gstreamer/gstreamer/), multimedia framework (not the default yet)
  - [GTK+](https://git.gnome.org/browse/gtk+/log/?h=wip/meson), the multi-platform toolkit used by GNOME (not merged yet)
+ - [GtkDApp](https://gitlab.com/csoriano/GtkDApp), an application template for developing Flatpak apps with Gtk+ and D
  - [Json-glib](https://git.gnome.org/browse/json-glib), GLib-based JSON manipulation library
  - [Libepoxy](https://github.com/anholt/libepoxy/), a library for handling OpenGL function pointer management
  - [Libgit2-glib](https://git.gnome.org/browse/libgit2-glib/), a GLib wrapper for libgit2
@@ -30,7 +32,8 @@ If you have a project that uses Meson that you want to add to this list, let us
  - [Pitivi](http://pitivi.org/), a nonlinear video editor
  - [Polari](https://git.gnome.org/browse/polari), an IRC client
  - [Sysprof](https://wiki.gnome.org/Apps/Sysprof), a profiling tool
- - [systemd](https://github.com/systemd/systemd/pull/5704), the init system (not merged yet)
+ - [systemd](https://github.com/systemd/systemd/pull/5704), the init system (not the default yet)
+ - [Xorg](https://cgit.freedesktop.org/xorg/xserver/) the X.org display server (not the default yet)
  - [Valum](https://github.com/valum-framework/valum), a micro web framework written in Vala
  - [Wayland and Weston](https://lists.freedesktop.org/archives/wayland-devel/2016-November/031984.html), a next generation display server (not merged yet)
  - [ZStandard](https://github.com/facebook/zstd/commit/4dca56ed832c6a88108a2484a8f8ff63d8d76d91) a compression algorithm developed at Facebook (not used by default)
diff --git a/docs/markdown/tmp.json b/docs/markdown/tmp.json
deleted file mode 100644
index 190d12f..0000000
--- a/docs/markdown/tmp.json
+++ /dev/null
@@ -1,29 +0,0 @@
-{
-  "functions": {
-    "add_global_arguments": {
-      "doc": ["Adds the positional arguments to the compiler command line for the language specified in `language` keyword argument. Note that there is no way to remove an argument set in this way.",
-        "If you have an argument that is only used in a subset of targets, you have to specify it in per-target flags.",
-        "The arguments are used in all compiler invocations with the exception of compile tests, because you might need to run a compile test with and without the argument in question. For this reason only the arguments explicitly specified are used during compile tests.",
-        "**Note:** Usually you should use `add_project_arguments` instead, because that works even when you project is used as a subproject.",
-        "**Note:** You must pass always arguments individually `arg1, arg2, ...` rather than as a string `'arg1 arg2', ...`"]
-        "arguments": [
-          {"name": "args1", "doc": "Some argument"}
-        ]
-    }
-  }
-  "objects": [
-    "meson": {
-      "doc": ["The `meson` object allows you to introspect various properties of the system. This object is always mapped in the `meson` variable. It has the following methods."]
-      "methods": [
-        "get_compiler": {
-          "arguments": [
-            {"name": "language", "doc": "returns [an object describing a compiler](#compiler-object), takes one positional argument which is the language to use. ",
-              "It also accepts one keyword argument, `native` which when set to true makes Meson return the compiler for the build machine (the \"native\" compiler)",
-              "and when false it returns the host compiler (the \"cross\" compiler). If `native` is omitted, Meson returns the \"cross\" compiler if we're currently",
-              " cross-compiling and the \"native\" compiler if we're not."}
-          ]
-        }
-      ]
-    }
-  ]
-}
diff --git a/docs/sitemap.txt b/docs/sitemap.txt
index 9dceb05..7246749 100644
--- a/docs/sitemap.txt
+++ b/docs/sitemap.txt
@@ -50,13 +50,13 @@ index.md
 	Reproducible-builds.md
 	howtox.md
 	Wrap-dependency-system-manual.md
-		fallback-wraptool.md
 		Adding-new-projects-to-wrapdb.md
 		Using-the-WrapDB.md
 		Using-wraptool.md
 		Wrap-best-practices-and-tips.md
 		Wrap-review-guidelines.md
 		Shipping-prebuilt-binaries-as-wraps.md
+		fallback-wraptool.md
 	Release-notes.md
 		Release-notes-for-0.41.0.md
 		Release-notes-for-0.40.0.md