Rewrap long text lines in docs. [skip ci]

docs/markdown/Adding-arguments.md

@@ -62,7 +62,8 @@ executable('prog', 'prog.cc', cpp_args : '-DCPPTHING')
 Here we create a C++ executable with an extra argument that is used
 during compilation but not for linking.
 
-You can find the parameter name for other languages in the [reference tables](Reference-tables.md).
+You can find the parameter name for other languages in the [reference
+tables](Reference-tables.md).
 
 Specifying extra linker arguments is done in the same way:
 

docs/markdown/Build-options.md

@@ -66,16 +66,16 @@ empty. The `value` parameter specifies the default value of the option
 and if it is unset then the values of `choices` will be used as the
 default.
 
-As of 0.47.0 -Dopt= and -Dopt=[] both pass an empty list, before this -Dopt=
+As of 0.47.0 -Dopt= and -Dopt=[] both pass an empty list, before this
-would pass a list with an empty string.
+-Dopt= would pass a list with an empty string.
 
 This type is available since version 0.44.0
 
 ### Features
 
-A `feature` option has three states: `enabled`, `disabled` or `auto`. It is intended
+A `feature` option has three states: `enabled`, `disabled` or `auto`.
-to be passed as value for the `required` keyword argument of most functions.
+It is intended to be passed as value for the `required` keyword
-Currently supported in
+argument of most functions. Currently supported in
 [`dependency()`](Reference-manual.md#dependency),
 [`find_library()`](Reference-manual.md#compiler-object),
 [`find_program()`](Reference-manual.md#find_program) and
@@ -85,10 +85,11 @@ Currently supported in
 - `auto` is the same as passing `required : false`.
 - `disabled` do not look for the dependency and always return 'not-found'.
 
-When getting the value of this type of option using `get_option()`, a special
+When getting the value of this type of option using `get_option()`, a
-[feature option object](Reference-manual.md#feature-option-object)
+special [feature option
-is returned instead of the string representation of the option's value.
+object](Reference-manual.md#feature-option-object) is returned instead
-This object can be passed to `required`:
+of the string representation of the option's value. This object can be
+passed to `required`:
 
 ```meson
 d = dependency('foo', required : get_option('myfeature'))
@@ -112,13 +113,14 @@ if get_option('myfeature').enabled()
 endif
 ```
 
-If the value of a `feature` option is set to `auto`, that value is overridden by
+If the value of a `feature` option is set to `auto`, that value is
-the global `auto_features` option (which defaults to `auto`). This is intended
+overridden by the global `auto_features` option (which defaults to
-to be used by packagers who want to have full control on which dependencies are
+`auto`). This is intended to be used by packagers who want to have
-required and which are disabled, and not rely on build-deps being installed
+full control on which dependencies are required and which are
-(at the right version) to get a feature enabled. They could set
+disabled, and not rely on build-deps being installed (at the right
-`auto_features=enabled` to enable all features and disable explicitly only the
+version) to get a feature enabled. They could set
-few they don't want, if any.
+`auto_features=enabled` to enable all features and disable explicitly
+only the few they don't want, if any.
 
 This type is available since version 0.47.0
 
@@ -200,8 +202,8 @@ option.
 
 ## Built-in build options
 
-There are a number of [built-in options][builtin_opts]. To get the current list execute `meson
+There are a number of [built-in options][builtin_opts]. To get the
-configure` in the build directory.
+current list execute `meson configure` in the build directory.
 
 [builtin_opts]: https://mesonbuild.com/Builtin-options.html
 
@@ -209,9 +211,10 @@ configure` in the build directory.
 
 #### Startup project
 
-The backend\_startup\_project option can be set to define the default project
+The `backend_startup_project` option can be set to define the default
-that will be executed with the "Start debugging F5" action in visual studio.
+project that will be executed with the "Start debugging F5" action in
-It should be the same name as an executable target name.
+visual studio. It should be the same name as an executable target
+name.
 
 ```meson
 project('my_project', 'c', default_options: ['backend_startup_project=my_exe'])
@@ -222,5 +225,5 @@ executable('my_exe', ...)
 
 #### Max links
 
-The backend\_max\_links can be set to limit the number of processes that ninja
+The `backend_max_links` can be set to limit the number of processes
-will use to link.
+that ninja will use to link.

docs/markdown/Builtin-options.md

@@ -11,19 +11,24 @@ universal options, base options, compiler options.
 ## Universal options
 
 A list of these options can be found by running `meson --help`. All
-these can be set by passing `-Doption=value` to `meson` (aka `meson setup`), or
+these can be set by passing `-Doption=value` to `meson` (aka `meson
-by setting them inside `default_options` of `project()` in your `meson.build`.
+setup`), or by setting them inside `default_options` of `project()` in
-Some options can also be set by `--option=value`, or `--option value`--- a list
+your `meson.build`. Some options can also be set by `--option=value`,
-is shown by running `meson setup --help`.
+or `--option value`--- a list is shown by running `meson setup
+--help`.
 
-For legacy reasons `--warnlevel` is the cli argument for the `warning_level` option.
+For legacy reasons `--warnlevel` is the cli argument for the
+`warning_level` option.
 
-They can also be edited after setup using `meson configure -Doption=value`.
+They can also be edited after setup using `meson configure
+-Doption=value`.
 
 Installation options are all relative to the prefix, except:
 
-* When the prefix is `/usr`: `sysconfdir` defaults to `/etc`, `localstatedir` defaults to `/var`, and `sharedstatedir` defaults to `/var/lib`
+* When the prefix is `/usr`: `sysconfdir` defaults to `/etc`,
-* When the prefix is `/usr/local`: `localstatedir` defaults to `/var/local`, and `sharedstatedir` defaults to `/var/local/lib`
+* `localstatedir` defaults to `/var`, and `sharedstatedir` defaults to
+* `/var/lib` When the prefix is `/usr/local`: `localstatedir` defaults
+* to `/var/local`, and `sharedstatedir` defaults to `/var/local/lib`
 
 ### Directories
 
@@ -44,21 +49,22 @@ Installation options are all relative to the prefix, except:
 | sysconfdir                           | etc           | Sysconf data directory |
 
 
-`prefix` defaults to `C:/` on Windows, and `/usr/local` otherwise. You should always
+`prefix` defaults to `C:/` on Windows, and `/usr/local` otherwise. You
-override this value.
+should always override this value.
 
-`libdir` is automatically detected based on your platform, it should be
+`libdir` is automatically detected based on your platform, it should
-correct when doing "native" (build machine == host machine) compilation. For
+be correct when doing "native" (build machine == host machine)
-cross compiles meson will try to guess the correct libdir, but it may not be
+compilation. For cross compiles meson will try to guess the correct
-accurate, especially on Linux where different distributions have different
+libdir, but it may not be accurate, especially on Linux where
-defaults. Using a [cross file](Cross-compilation.md#defining-the-environment),
+different distributions have different defaults. Using a [cross
-particularly the paths section may be necessary.
+file](Cross-compilation.md#defining-the-environment), particularly the
+paths section may be necessary.
 
 ### Core options
 
-Options that are labeled "per machine" in the table are set per machine. See
+Options that are labeled "per machine" in the table are set per
-the [specifying options per machine](#specifying-options-per-machine) section
+machine. See the [specifying options per
-for details.
+machine](#specifying-options-per-machine) section for details.
 
 | Option                               | Default value | Description                                                    | Is per machine | Is per subproject |
 | ------                               | ------------- | -----------                                                    | -------------- | ----------------- |
@@ -82,13 +88,13 @@ for details.
 | wrap_mode {default, nofallback,<br>nodownload, forcefallback, nopromote} | default | Wrap mode to use                 | no             | no                |
 | force_fallback_for                   | []            | Force fallback for those dependencies                          | no             | no                |
 
-<a name="build-type-options"></a>
+<a name="build-type-options"></a> For setting optimization levels and
-For setting optimization levels and toggling debug, you can either set the
+toggling debug, you can either set the `buildtype` option, or you can
-`buildtype` option, or you can set the `optimization` and `debug` options which
+set the `optimization` and `debug` options which give finer control
-give finer control over the same. Whichever you decide to use, the other will
+over the same. Whichever you decide to use, the other will be deduced
-be deduced from it. For example, `-Dbuildtype=debugoptimized` is the same as
+from it. For example, `-Dbuildtype=debugoptimized` is the same as
-`-Ddebug=true -Doptimization=2` and vice-versa. This table documents the
+`-Ddebug=true -Doptimization=2` and vice-versa. This table documents
-two-way mapping:
+the two-way mapping:
 
 | buildtype      | debug | optimization |
 | ---------      | ----- | ------------ |
@@ -102,15 +108,16 @@ All other combinations of `debug` and `optimization` set `buildtype` to `'custom
 
 ## Base options
 
-These are set in the same way as universal options, either by `-Doption=value`, 
+These are set in the same way as universal options, either by
-or by setting them inside `default_options` of `project()` in your `meson.build`.
+`-Doption=value`, or by setting them inside `default_options` of
-However, they cannot be shown in the
+`project()` in your `meson.build`. However, they cannot be shown in
-output of `meson --help` because they depend on both the current platform and
+the output of `meson --help` because they depend on both the current
-the compiler that will be selected. The only way to see them is to setup
+platform and the compiler that will be selected. The only way to see
-a builddir and then run `meson configure` on it with no options.
+them is to setup a builddir and then run `meson configure` on it with
+no options.
 
-The following options are available. Note that they may not be available on all
+The following options are available. Note that they may not be
-platforms or with all compilers:
+available on all platforms or with all compilers:
 
 | Option      | Default value | Possible values         | Description |
 | ----------- | ------------- | ---------------         | ----------- |
@@ -131,10 +138,11 @@ platforms or with all compilers:
 The value of `b_sanitize` can be one of: `none`, `address`, `thread`,
 `undefined`, `memory`, `address,undefined`.
 
-<a name="b_vscrt-from_buildtype"></a>
+<a name="b_vscrt-from_buildtype"></a> The default value of `b_vscrt`
-The default value of `b_vscrt` is `from_buildtype`. The following table is used
+is `from_buildtype`. The following table is used internally to pick
-internally to pick the CRT compiler arguments for `from_buildtype` or
+the CRT compiler arguments for `from_buildtype` or
-`static_from_buildtype` *(since 0.56)* based on the value of the `buildtype` option:
+`static_from_buildtype` *(since 0.56)* based on the value of the
+`buildtype` option:
 
 | buildtype      | from_buildtype | static_from_buildtype |
 | --------       | -------------- | --------------------- |
@@ -147,21 +155,22 @@ internally to pick the CRT compiler arguments for `from_buildtype` or
 ### Notes about Apple Bitcode support
 
 `b_bitcode` will pass `-fembed-bitcode` while compiling and will pass
-`-Wl,-bitcode_bundle` while linking. These options are incompatible with
+`-Wl,-bitcode_bundle` while linking. These options are incompatible
-`b_asneeded`, so that option will be silently disabled.
+with `b_asneeded`, so that option will be silently disabled.
 
-[Shared modules](Reference-manual.md#shared_module) will not have bitcode
+[Shared modules](Reference-manual.md#shared_module) will not have
-embedded because `-Wl,-bitcode_bundle` is incompatible with both `-bundle` and
+bitcode embedded because `-Wl,-bitcode_bundle` is incompatible with
-`-Wl,-undefined,dynamic_lookup` which are necessary for shared modules to work.
+both `-bundle` and `-Wl,-undefined,dynamic_lookup` which are necessary
+for shared modules to work.
 
 ## Compiler options
 
 Same caveats as base options above.
 
-The following options are available. They can be set by passing `-Doption=value`
+The following options are available. They can be set by passing
-to `meson`. Note that both the options themselves and
+`-Doption=value` to `meson`. Note that both the options themselves and
-the possible values they can take will depend on the target platform or
+the possible values they can take will depend on the target platform
-compiler being used:
+or compiler being used:
 
 | Option           | Default value | Possible values                          | Description |
 | ------           | ------------- | ---------------                          | ----------- |
@@ -180,56 +189,60 @@ compiler being used:
 | cpp_winlibs      | see below     | free-form comma-separated list           | Standard Windows libs to link against |
 | fortran_std      | none          | [none, legacy, f95, f2003, f2008, f2018] | Fortran language standard to use |
 
-The default values of `c_winlibs` and `cpp_winlibs` are in compiler-specific
+The default values of `c_winlibs` and `cpp_winlibs` are in
-argument forms, but the libraries are: kernel32, user32, gdi32, winspool,
+compiler-specific argument forms, but the libraries are: kernel32,
-shell32, ole32, oleaut32, uuid, comdlg32, advapi32.
+user32, gdi32, winspool, shell32, ole32, oleaut32, uuid, comdlg32,
+advapi32.
 
-All these `<lang>_*` options are specified per machine. See below in the
+All these `<lang>_*` options are specified per machine. See below in
-[specifying options per machine](#specifying-options-per-machine) section on
+the [specifying options per machine](#specifying-options-per-machine)
-how to do this in cross builds.
+section on how to do this in cross builds.
 
-When using MSVC, `cpp_eh=none` will result in no exception flags being passed,
+When using MSVC, `cpp_eh=none` will result in no exception flags being
-while the `cpp_eh=[value]` will result in `/EH[value]`.
+passed, while the `cpp_eh=[value]` will result in `/EH[value]`. Since
-Since *0.51.0* `cpp_eh=default` will result in `/EHsc` on MSVC. When using
+*0.51.0* `cpp_eh=default` will result in `/EHsc` on MSVC. When using
-gcc-style compilers, nothing is passed (allowing exceptions to work), while
+gcc-style compilers, nothing is passed (allowing exceptions to work),
-`cpp_eh=none` passes `-fno-exceptions`.
+while `cpp_eh=none` passes `-fno-exceptions`.
 
-Since *0.54.0* The `<lang>_thread_count` option can be used to control the
+Since *0.54.0* The `<lang>_thread_count` option can be used to control
-value passed to `-s PTHREAD_POOL_SIZE` when using emcc. No other c/c++
+the value passed to `-s PTHREAD_POOL_SIZE` when using emcc. No other
-compiler supports this option.
+c/c++ compiler supports this option.
 
 ## Specifying options per machine
 
-Since *0.51.0*, some options are specified per machine rather than globally for
+Since *0.51.0*, some options are specified per machine rather than
-all machine configurations. Prefixing the option with `build.` just affects the
+globally for all machine configurations. Prefixing the option with
-build machine configuration, while unprefixed just affects the host machine
+`build.` just affects the build machine configuration, while
-configuration, respectively. For example:
+unprefixed just affects the host machine configuration, respectively.
+For example:
 
- - `build.pkg_config_path` controls the paths pkg-config will search for just
+ - `build.pkg_config_path` controls the paths pkg-config will search
-   `native: true` dependencies (build machine).
+   for just `native: true` dependencies (build machine).
 
- - `pkg_config_path` controls the paths pkg-config will search for just
+ - `pkg_config_path` controls the paths pkg-config will search for
-   `native: false` dependencies (host machine).
+   just `native: false` dependencies (host machine).
 
-This is useful for cross builds. In the native builds, build = host, and the
+This is useful for cross builds. In the native builds, build = host,
-unprefixed option alone will suffice.
+and the unprefixed option alone will suffice.
 
-Prior to *0.51.0*, these options just effected native builds when specified on
+Prior to *0.51.0*, these options just effected native builds when
-the command line, as there was no `build.` prefix. Similarly named fields in
+specified on the command line, as there was no `build.` prefix.
-the `[properties]` section of the cross file would effect cross compilers, but
+Similarly named fields in the `[properties]` section of the cross file
-the code paths were fairly different allowing differences in behavior to crop
+would effect cross compilers, but the code paths were fairly different
-out.
+allowing differences in behavior to crop out.
 
 ## Specifying options per subproject
 
-Since *0.54.0* `default_library` and `werror` built-in options can be defined
+Since *0.54.0* `default_library` and `werror` built-in options can be
-per subproject. This is useful for example when building shared libraries in the
+defined per subproject. This is useful for example when building
-main project, but static link a subproject, or when the main project must build
+shared libraries in the main project, but static link a subproject, or
-with no warnings but some subprojects cannot.
+when the main project must build with no warnings but some subprojects
+cannot.
 
-Most of the time this would be used either by the parent project by setting
+Most of the time this would be used either by the parent project by
-subproject's default_options (e.g. `subproject('foo', default_options: 'default_library=static')`),
+setting subproject's default_options (e.g. `subproject('foo',
-or by the user using the command line `-Dfoo:default_library=static`.
+default_options: 'default_library=static')`), or by the user using the
+command line `-Dfoo:default_library=static`.
 
 The value is overridden in this order:
 - Value from parent project

docs/markdown/CMake-module.md

@@ -48,13 +48,13 @@ The `subproject` method is almost identical to the normal meson
 `subproject` function. The only difference is that a CMake project
 instead of a meson project is configured.
 
-The returned `sub_proj` supports the same options as a "normal" subproject.
+The returned `sub_proj` supports the same options as a "normal"
-Meson automatically detects CMake build targets, which can be accessed with
+subproject. Meson automatically detects CMake build targets, which can
-the methods listed [below](#subproject-object).
+be accessed with the methods listed [below](#subproject-object).
 
 It is usually enough to just use the dependency object returned by the
-`dependency()` method in the build targets. This is almost identical to
+`dependency()` method in the build targets. This is almost identical
-using `declare_dependency()` object from a normal meson subproject.
+to using `declare_dependency()` object from a normal meson subproject.
 
 It is also possible to use executables defined in the CMake project as code
 generators with the `target()` method:
@@ -111,22 +111,24 @@ sub_pro = cmake.subproject('someLibProject', options: opt_var)
 # Further changes to opt_var have no effect
 ```
 
-See [the CMake options object](#cmake-options-object) for a complete reference
+See [the CMake options object](#cmake-options-object) for a complete
-of all supported functions.
+reference of all supported functions.
 
 The CMake configuration options object is very similar to the
-[configuration data object](Reference-manual.md#configuration-data-object) object
+[configuration data
-returned by [`configuration_data`](Reference-manual.md#configuration_data). It
+object](Reference-manual.md#configuration-data-object) object returned
+by [`configuration_data`](Reference-manual.md#configuration_data). It
 is generated by the `subproject_options` function
 
-All configuration options have to be set *before* the subproject is configured
+All configuration options have to be set *before* the subproject is
-and must be passed to the `subproject` method via the `options` key. Altering
+configured and must be passed to the `subproject` method via the
-the configuration object won't have any effect on previous `cmake.subproject`
+`options` key. Altering the configuration object won't have any effect
-calls.
+on previous `cmake.subproject` calls.
 
-In earlier meson versions CMake command-line parameters could be set with the
+In earlier meson versions CMake command-line parameters could be set
-`cmake_options` kwarg. However, this feature is deprecated since 0.55.0 and only
+with the `cmake_options` kwarg. However, this feature is deprecated
-kept for compatibility. It will not work together with the `options` kwarg.
+since 0.55.0 and only kept for compatibility. It will not work
+together with the `options` kwarg.
 
 ### `subproject` object
 
@@ -151,9 +153,9 @@ and supports the following methods:
 
 ### `cmake options` object
 
-This object is returned by the `subproject_options()` function and consumed by
+This object is returned by the `subproject_options()` function and
-the `options` kwarg of the `subproject` function. The following methods are
+consumed by the `options` kwarg of the `subproject` function. The
-supported:
+following methods are supported:
 
  - `add_cmake_defines({'opt1': val1, ...})` add additional CMake commandline defines
  - `set_override_option(opt, val)` set specific [build options](Build-options.md)
@@ -165,39 +167,42 @@ supported:
  - `append_link_args(arg1, ...)` append linger args to the targets
  - `clear()` reset all data in the `cmake options` object
 
-The methods `set_override_option`, `set_install`, `append_compile_args` and
+The methods `set_override_option`, `set_install`,
-`append_link_args` support the optional `target` kwarg. If specified, the set
+`append_compile_args` and `append_link_args` support the optional
-options affect the specific target. The effect of the option is global for the
+`target` kwarg. If specified, the set options affect the specific
-subproject otherwise.
+target. The effect of the option is global for the subproject
+otherwise.
 
-If, for instance, `opt_var.set_install(false)` is called, no target will be
+If, for instance, `opt_var.set_install(false)` is called, no target
-installed regardless of what is set by CMake. However, it is still possible to
+will be installed regardless of what is set by CMake. However, it is
-install specific targets (here `foo`) by setting the `target` kwarg:
+still possible to install specific targets (here `foo`) by setting the
-`opt_var.set_install(true, target: 'foo')`
+`target` kwarg: `opt_var.set_install(true, target: 'foo')`
 
-Options that are not set won't affect the generated subproject. So, if for
+Options that are not set won't affect the generated subproject. So, if
-instance, `set_install` was not called then the values extracted from CMake will
+for instance, `set_install` was not called then the values extracted
-be used.
+from CMake will be used.
 
 ### Cross compilation
 
 *New in 0.56.0*
 
-Meson will try to automatically guess most of the required CMake toolchain
+Meson will try to automatically guess most of the required CMake
-variables from existing entries in the cross and native files. These variables
+toolchain variables from existing entries in the cross and native
-will be stored in an automatically generate CMake toolchain file in the build
+files. These variables will be stored in an automatically generate
-directory. The remaining variables that can't be guessed can be added by the
+CMake toolchain file in the build directory. The remaining variables
-user in the `[cmake]` cross/native file section (*new in 0.56.0*).
+that can't be guessed can be added by the user in the `[cmake]`
+cross/native file section (*new in 0.56.0*).
 
 Adding a manual CMake toolchain file is also supported with the
-`cmake_toolchain_file` setting in the `[properties]` section. Directly setting
+`cmake_toolchain_file` setting in the `[properties]` section. Directly
-a CMake toolchain file with `-DCMAKE_TOOLCHAIN_FILE=/path/to/some/Toolchain.cmake`
+setting a CMake toolchain file with
-in the `meson.build` is **not** supported since the automatically generated
+`-DCMAKE_TOOLCHAIN_FILE=/path/to/some/Toolchain.cmake` in the
-toolchain file is also used by Meson to inject arbitrary code into CMake to
+`meson.build` is **not** supported since the automatically generated
-enable the CMake subproject support.
+toolchain file is also used by Meson to inject arbitrary code into
+CMake to enable the CMake subproject support.
 
-The closest configuration to only using a manual CMake toolchain file would be
+The closest configuration to only using a manual CMake toolchain file
-to set these options in the machine file:
+would be to set these options in the machine file:
 
 ```ini
 [properties]
@@ -210,17 +215,19 @@ cmake_defaults       = false
 # No entries in this section
 ```
 
-This will result in a toolchain file with just the bare minimum to enable the
+This will result in a toolchain file with just the bare minimum to
-CMake subproject support and `include()` the `cmake_toolchain_file` as the
+enable the CMake subproject support and `include()` the
-last instruction.
+`cmake_toolchain_file` as the last instruction.
 
-For more information see the [cross and native file specification](Machine-files.md).
+For more information see the [cross and native file
+specification](Machine-files.md).
 
 ## CMake configuration files
 
 ### cmake.write_basic_package_version_file()
 
-This function is the equivalent of the corresponding [CMake function](https://cmake.org/cmake/help/v3.11/module/CMakePackageConfigHelpers.html#generating-a-package-version-file),
+This function is the equivalent of the corresponding [CMake
+function](https://cmake.org/cmake/help/v3.11/module/CMakePackageConfigHelpers.html#generating-a-package-version-file),
 it generates a `name` package version file.
 
 * `name`: the name of the package.
@@ -242,10 +249,13 @@ cmake.write_basic_package_version_file(name: 'myProject', version: '1.0.0')
 
 ### cmake.configure_package_config_file()
 
-This function is the equivalent of the corresponding [CMake function](https://cmake.org/cmake/help/v3.11/module/CMakePackageConfigHelpers.html#generating-a-package-configuration-file),
+This function is the equivalent of the corresponding [CMake
-it generates a `name` package configuration file from the `input` template file. Just like the cmake function
+function](https://cmake.org/cmake/help/v3.11/module/CMakePackageConfigHelpers.html#generating-a-package-configuration-file),
-in this file the `@PACKAGE_INIT@` statement will be replaced by the appropriate piece of cmake code.
+it generates a `name` package configuration file from the `input`
-The equivalent `PATH_VARS` argument is given through the `configuration` parameter.
+template file. Just like the cmake function in this file the
+`@PACKAGE_INIT@` statement will be replaced by the appropriate piece
+of cmake code. The equivalent `PATH_VARS` argument is given through
+the `configuration` parameter.
 
 * `name`: the name of the package.
 * `input`: the template file where that will be treated for variable substitutions contained in `configuration`.

docs/markdown/Commands.md

@@ -1,18 +1,21 @@
 # Command-line commands
 
-There are two different ways of invoking Meson. First, you can run it directly
+There are two different ways of invoking Meson. First, you can run it
-from the source tree with the command `/path/to/source/meson.py`. Meson may
+directly from the source tree with the command
-also be installed in which case the command is simply `meson`. In this manual
+`/path/to/source/meson.py`. Meson may also be installed in which case
-we only use the latter format for simplicity.
+the command is simply `meson`. In this manual we only use the latter
+format for simplicity.
 
 Meson is invoked using the following syntax:
 `meson [COMMAND] [COMMAND_OPTIONS]`
 
-This section describes all available commands and some of their Optional arguments.
+This section describes all available commands and some of their
-The most common workflow is to run [`setup`](#setup), followed by [`compile`](#compile), and then [`install`](#install).
+Optional arguments. The most common workflow is to run
+[`setup`](#setup), followed by [`compile`](#compile), and then
+[`install`](#install).
 
-For the full list of all available options for a specific command use the following syntax:
+For the full list of all available options for a specific command use
-`meson COMMAND --help`
+the following syntax: `meson COMMAND --help`
 
 ### configure
 
@@ -24,7 +27,8 @@ Changes options of a configured meson project.
 
 Most arguments are the same as in [`setup`](#setup).
 
-Note: reconfiguring project will not reset options to their default values (even if they were changed in `meson.build`).
+Note: reconfiguring project will not reset options to their default
+values (even if they were changed in `meson.build`).
 
 #### Examples:
 
@@ -59,7 +63,8 @@ Builds a default or a specified target of a configured meson project.
 - `PATH`: path to the target relative to the root `meson.build` file. Note: relative path for a target specified in the root `meson.build` is `./`.
 - `TYPE`: type of the target. Can be one of the following: 'executable', 'static_library', 'shared_library', 'shared_module', 'custom', 'run', 'jar'.
   
-`PATH` and/or `TYPE` can be omitted if the resulting `TARGET` can be used to uniquely identify the target in `meson.build`.
+`PATH` and/or `TYPE` can be omitted if the resulting `TARGET` can be
+used to uniquely identify the target in `meson.build`.
 
 #### Backend specific arguments
 
@@ -67,7 +72,8 @@ Builds a default or a specified target of a configured meson project.
 
 `BACKEND-args` use the following syntax:
 
-If you only pass a single string, then it is considered to have all values separated by commas. Thus invoking the following command:
+If you only pass a single string, then it is considered to have all
+values separated by commas. Thus invoking the following command:
 
 ```
 $ meson compile --ninja-args=-n,-d,explain
@@ -75,7 +81,8 @@ $ meson compile --ninja-args=-n,-d,explain
 
 would add `-n`, `-d` and `explain` arguments to ninja invocation.
 
-If you need to have commas or spaces in your string values, then you need to pass the value with proper shell quoting like this:
+If you need to have commas or spaces in your string values, then you
+need to pass the value with proper shell quoting like this:
 
 ```
 $ meson compile "--ninja-args=['a,b', 'c d']"
@@ -89,16 +96,20 @@ meson compile -C builddir
 ```
 
 Execute a dry run on ninja backend with additional debug info:
+
 ```
 meson compile --ninja-args=-n,-d,explain
 ```
 
-Build three targets: two targets that have the same `foo` name, but different type, and a `bar` target:
+Build three targets: two targets that have the same `foo` name, but
+different type, and a `bar` target:
+
 ```
 meson compile foo:shared_library foo:static_library bar
 ```
 
 Produce a coverage html report (if available):
+
 ```
 meson compile coverage-html
 ```
@@ -150,6 +161,7 @@ Displays information about a configured meson project.
 #### Examples:
 
 Display basic information about a configured project in `builddir`:
+
 ```
 meson introspect builddir --projectinfo
 ```
@@ -200,7 +212,8 @@ This is the default meson command (invoked if there was no COMMAND supplied).
 
 {{ setup_arguments.inc }}
 
-See [meson introduction page](Running-Meson.md#configuring-the-build-directory) for more info.
+See [meson introduction
+page](Running-Meson.md#configuring-the-build-directory) for more info.
 
 #### Examples:
 

docs/markdown/Compiler-properties.md

@@ -41,8 +41,8 @@ either `gcc` or `msvc`, or that its arguments are not like either. This should
 only be used to select the syntax of the arguments, such as those to test
 with `has_argument`.
 
-See [reference tables](Reference-tables.md#compiler-ids) for a list of supported compiler
+See [reference tables](Reference-tables.md#compiler-ids) for a list of
-ids and their argument type.
+supported compiler ids and their argument type.
 
 ## Does code compile?
 
@@ -167,10 +167,10 @@ not be determined.
 
 ## Does a function exist?
 
-Just having a header doesn't say anything about its
+Just having a header doesn't say anything about its contents.
-contents. Sometimes you need to explicitly check if some function
+Sometimes you need to explicitly check if some function exists. This
-exists. This is how we would check whether the function `open_memstream`
+is how we would check whether the function `open_memstream` exists in
-exists in header `stdio.h`
+header `stdio.h`
 
 ```meson
 if compiler.has_function('open_memstream', prefix : '#include <stdio.h>')
@@ -180,18 +180,18 @@ endif
 
 Note that, on macOS programs can be compiled targeting older macOS
 versions than the one that the program is compiled on. It can't be
-assumed that the OS version that is compiled on matches the OS
+assumed that the OS version that is compiled on matches the OS version
-version that the binary will run on.
+that the binary will run on.
 
 Therefore when detecting function availability with `has_function`, it
 is important to specify the correct header in the prefix argument.
 
 In the example above, the function `open_memstream` is detected, which
-was introduced in macOS 10.13. When the user builds on macOS 10.13, but
+was introduced in macOS 10.13. When the user builds on macOS 10.13,
-targeting macOS 10.11 (`-mmacosx-version-min=10.11`), this will correctly
+but targeting macOS 10.11 (`-mmacosx-version-min=10.11`), this will
-report the function as missing. Without the header however, it would lack
+correctly report the function as missing. Without the header however,
-the necessary availability information and incorrectly report the function
+it would lack the necessary availability information and incorrectly
-as available.
+report the function as available.
 
 ## Does a structure contain a member?
 

docs/markdown/Conference-presentations.md

@@ -1,17 +1,31 @@
 # Conference presentations on Meson
 
-- FOSDEM 2014, [Introducing the Meson build system](https://video.fosdem.org/2014/H2215_Ferrer/Sunday/Introducing_the_Meson_build_system.webm) (jpakkane)
+- FOSDEM 2014, [Introducing the Meson build
+  system](https://video.fosdem.org/2014/H2215_Ferrer/Sunday/Introducing_the_Meson_build_system.webm)
+  (jpakkane)
 
-- LCA 2015, [Making build systems not suck](https://www.youtube.com/watch?v=KPi0AuVpxLI) (jpakkane)
+- LCA 2015, [Making build systems not
+  suck](https://www.youtube.com/watch?v=KPi0AuVpxLI) (jpakkane)
 
-- GUADEC 2015, [Improving the way Gnome apps are built](https://www.youtube.com/watch?v=wTf0NjjNwTU) (jpakkane)
+- GUADEC 2015, [Improving the way Gnome apps are
+  built](https://www.youtube.com/watch?v=wTf0NjjNwTU) (jpakkane)
 
-- GStreamer conference 2015, [Done in 6.0 seconds](https://gstconf.ubicast.tv/videos/done-in-60-seconds-a-new-build-system-for-gstreamer) (jpakkane)
+- GStreamer conference 2015, [Done in 6.0
+  seconds](https://gstconf.ubicast.tv/videos/done-in-60-seconds-a-new-build-system-for-gstreamer)
+  (jpakkane)
 
-- LCA 2016, [Builds, dependencies and deployment in the modern multiplatform world](https://www.youtube.com/watch?v=CTJtKtQ8R5k) (jpakkane)
+- LCA 2016, [Builds, dependencies and deployment in the modern
+  multiplatform world](https://www.youtube.com/watch?v=CTJtKtQ8R5k)
+  (jpakkane)
 
-- GUADEC 2016, [Making your GNOME app compile 2.4x faster](https://media.ccc.de/v/44-making_your_gnome_app_compile_24x_faster) (nirbheek)
+- GUADEC 2016, [Making your GNOME app compile 2.4x
+  faster](https://media.ccc.de/v/44-making_your_gnome_app_compile_24x_faster)
+  (nirbheek)
 
-- Libre Application Summit 2016, [New world, new tools](https://youtu.be/0-gx1qU2pPo) (jpakkane)
+- Libre Application Summit 2016, [New world, new
+  tools](https://youtu.be/0-gx1qU2pPo) (jpakkane)
 
-- GStreamer conference 2016, [GStreamer Development on Windows and faster builds everywhere with Meson](https://gstconf.ubicast.tv/videos/gstreamer-development-on-windows-ans-faster-builds-everywhere-with-meson/) (tpm)
+- GStreamer conference 2016, [GStreamer Development on Windows and
+  faster builds everywhere with
+  Meson](https://gstconf.ubicast.tv/videos/gstreamer-development-on-windows-ans-faster-builds-everywhere-with-meson/)
+  (tpm)

docs/markdown/Configuration.md

@@ -115,19 +115,20 @@ Will produce:
 
 ## Dealing with file encodings
 
-The default meson file encoding to configure files is utf-8. If you need to
+The default meson file encoding to configure files is utf-8. If you
-configure a file that is not utf-8 encoded the encoding keyword will allow
+need to configure a file that is not utf-8 encoded the encoding
-you to specify which file encoding to use. It is however strongly advised to
+keyword will allow you to specify which file encoding to use. It is
-convert your non utf-8 file to utf-8 whenever possible. Supported file
+however strongly advised to convert your non utf-8 file to utf-8
-encodings are those of python3, see [standard-encodings](https://docs.python.org/3/library/codecs.html#standard-encodings).
+whenever possible. Supported file encodings are those of python3, see
+[standard-encodings](https://docs.python.org/3/library/codecs.html#standard-encodings).
 
 ## Using dictionaries
 
-Since *0.49.0* `configuration_data()` takes an optional dictionary as first
+Since *0.49.0* `configuration_data()` takes an optional dictionary as
-argument. If provided, each key/value pair is added into the
+first argument. If provided, each key/value pair is added into the
 `configuration_data` as if `set()` method was called for each of them.
-`configure_file()`'s `configuration` kwarg also accepts a dictionary instead of
+`configure_file()`'s `configuration` kwarg also accepts a dictionary
-a configuration_data object.
+instead of a configuration_data object.
 
 Example:
 ```meson

docs/markdown/Configuring-a-build-directory.md

@@ -11,9 +11,9 @@ options provided in your `meson_options.txt` file and so on.
 
 The main tool for this is the `meson configure` command.
 
-You invoke `meson configure` by giving it the location of your build dir. If
+You invoke `meson configure` by giving it the location of your build
-omitted, the current working directory is used instead. Here's a
+dir. If omitted, the current working directory is used instead. Here's
-sample output for a simple project.
+a sample output for a simple project.
 
     Core properties
 
@@ -109,11 +109,12 @@ you would issue the following command.
 
     meson configure -Dprefix=/tmp/testroot
 
-Then you would run your build command (usually `meson compile`), which would
+Then you would run your build command (usually `meson compile`), which
-cause Meson to detect that the build setup has changed and do all the
+would cause Meson to detect that the build setup has changed and do
-work required to bring your build tree up to date.
+all the work required to bring your build tree up to date.
 
 Since 0.50.0, it is also possible to get a list of all build options
-by invoking [`meson configure`](Commands.md#configure) with the project source directory or
+by invoking [`meson configure`](Commands.md#configure) with the
-the path to the root `meson.build`. In this case, meson will print the
+project source directory or the path to the root `meson.build`. In
-default values of all options similar to the example output from above.
+this case, meson will print the default values of all options similar
+to the example output from above.

docs/markdown/Contact-information.md

@@ -8,7 +8,7 @@ If you find bugs, please file them in the [issue
 tracker](https://github.com/jpakkane/meson/issues).
 
 The maintainer of Meson is Jussi Pakkanen. You should usually not
-contact him privately but rather use the channels listed
+contact him privately but rather use the channels listed above.
-above. However if such a need arises, he can be reached at gmail where
+However if such a need arises, he can be reached at gmail where his
-his username is `jpakkane` (that is not a typo, the last letter is
+username is `jpakkane` (that is not a typo, the last letter is indeed
-indeed *e*).
+*e*).

docs/markdown/Continuous-Integration.md

@@ -42,8 +42,8 @@ script:
 
 ## CircleCi for Linux (with Docker)
 
-[CircleCi](https://circleci.com/) can work for spinning all of the Linux images you wish.
+[CircleCi](https://circleci.com/) can work for spinning all of the
-Here's a sample `yml` file for use with that.
+Linux images you wish. Here's a sample `yml` file for use with that.
 
 ```yaml
 version: 2.1
@@ -99,11 +99,14 @@ workflows:
 
 ## AppVeyor for Windows
 
-For CI on Windows, [AppVeyor](https://www.appveyor.com/) has a wide selection of
+For CI on Windows, [AppVeyor](https://www.appveyor.com/) has a wide
-[default configurations](https://www.appveyor.com/docs/windows-images-software/).
+selection of [default
-AppVeyor also has [MacOS](https://www.appveyor.com/docs/macos-images-software/) and
+configurations](https://www.appveyor.com/docs/windows-images-software/).
-[Linux](https://www.appveyor.com/docs/linux-images-software/) CI images.
+AppVeyor also has
-This is a sample `appveyor.yml` file for Windows with Visual Studio 2015 and 2017.
+[MacOS](https://www.appveyor.com/docs/macos-images-software/) and
+[Linux](https://www.appveyor.com/docs/linux-images-software/) CI
+images. This is a sample `appveyor.yml` file for Windows with Visual
+Studio 2015 and 2017.
 
 ```yaml
 image: Visual Studio 2017
@@ -154,7 +157,10 @@ For Qt 5, add the following line near the `PYTHON_ROOT` assignment:
 
 And afterwards add `%QT_ROOT%\bin` to the `PATH` variable.
 
-You might have to adjust your build matrix as there are, for example, no msvc2017 32-bit builds. Visit the [Build Environment](https://www.appveyor.com/docs/build-environment/) page in the AppVeyor docs for more details.
+You might have to adjust your build matrix as there are, for example,
+no msvc2017 32-bit builds. Visit the [Build
+Environment](https://www.appveyor.com/docs/build-environment/) page in
+the AppVeyor docs for more details.
 
 ### Boost
 
@@ -193,10 +199,13 @@ script:
 
 ## GitHub Actions
 
-GitHub Actions are distinct from Azure Pipelines in their workflow syntax.
+GitHub Actions are distinct from Azure Pipelines in their workflow
-It can be easier to setup specific CI tasks in Actions than Pipelines, depending on the particular task.
+syntax. It can be easier to setup specific CI tasks in Actions than
-This is an example file: .github/workflows/ci_meson.yml  supposing the project is C-based, using GCC on Linux, Mac and Windows.
+Pipelines, depending on the particular task. This is an example file:
-The optional `on:` parameters only run this CI when the C code is changed--corresponding ci_python.yml might run only on "**.py" file changes.
+.github/workflows/ci_meson.yml supposing the project is C-based, using
+GCC on Linux, Mac and Windows. The optional `on:` parameters only run
+this CI when the C code is changed--corresponding ci_python.yml might
+run only on "**.py" file changes.
 
 ```yml
 name: ci_meson

docs/markdown/Contributing.md

@@ -36,7 +36,8 @@ Every new feature requires some extra steps, namely:
 - Must include a project test under `test cases/`, or if that's not
   possible or if the test requires a special environment, it must go
   into `run_unittests.py`.
-- Must be registered with the [FeatureChecks framework](Release-notes-for-0.47.0.md#feature-detection-based-on-meson_version-in-project)
+- Must be registered with the [FeatureChecks
+  framework](Release-notes-for-0.47.0.md#feature-detection-based-on-meson_version-in-project)
   that will warn the user if they try to use a new feature while
   targeting an older meson version.
 - Needs a release note snippet inside `docs/markdown/snippets/` with
@@ -155,21 +156,23 @@ should be implemented as a Python script. The goal of test projects is
 also to provide sample projects that end users can use as a base for
 their own projects.
 
-All project tests follow the same pattern: they are configured, compiled, tests
+All project tests follow the same pattern: they are configured,
-are run and finally install is run. Passing means that configuring, building and
+compiled, tests are run and finally install is run. Passing means that
-tests succeed and that installed files match those expected.
+configuring, building and tests succeed and that installed files match
+those expected.
 
-Any tests that require more thorough analysis, such as checking that certain
+Any tests that require more thorough analysis, such as checking that
-compiler arguments can be found in the command line or that the generated
+certain compiler arguments can be found in the command line or that
-pkg-config files actually work should be done with a unit test.
+the generated pkg-config files actually work should be done with a
+unit test.
 
 Additionally:
 
 * `crossfile.ini` and `nativefile.ini` are passed to the configure step with
 `--cross-file` and `--native-file` options, respectively.
 
-* `mlog.cmd_ci_include()` can be called from anywhere inside meson to capture the
+* `mlog.cmd_ci_include()` can be called from anywhere inside meson to
-contents of an additional file into the CI log on failure.
+capture the contents of an additional file into the CI log on failure.
 
 Projects needed by unit tests are in the `test cases/unit`
 subdirectory. They are not run as part of `./run_project_tests.py`.
@@ -261,9 +264,15 @@ Except for the `file` and `expr` types, all paths should be provided *without* a
 | `version`  | `shared_lib`, `pdb`        | Sets the version to look for appropriately per-platform                       |
 | `language` | `pdb`                      | Determines which compiler/linker determines the existence of this file        |
 
-The `shared_lib` and `pdb` types takes an optional additional parameter, `version`, this is us a string in `X.Y.Z` format that will be applied to the library. Each version to be tested must have a single version. The harness will apply this correctly per platform:
+The `shared_lib` and `pdb` types takes an optional additional
+parameter, `version`, this is us a string in `X.Y.Z` format that will
+be applied to the library. Each version to be tested must have a
+single version. The harness will apply this correctly per platform:
 
-`pdb` takes an optional `language` argument. This determines which compiler/linker should generate the pdb file. Because it's possible to mix compilers that do and don't generate pdb files (dmd's optlink doesn't). Currently this is only needed when mixing D and C code.
+`pdb` takes an optional `language` argument. This determines which
+compiler/linker should generate the pdb file. Because it's possible to
+mix compilers that do and don't generate pdb files (dmd's optlink
+doesn't). Currently this is only needed when mixing D and C code.
 
 ```json
 {
@@ -273,10 +282,14 @@ The `shared_lib` and `pdb` types takes an optional additional parameter, `versio
 }
 ```
 
-This will be applied appropriately per platform. On windows this expects `lib.dll` and `lib-1.dll`. on MacOS it expects `liblib.dylib` and `liblib.1.dylib`. On other Unices it expects `liblib.so`, `liblib.so.1`, and `liblib.so.1.2.3`.
+This will be applied appropriately per platform. On windows this
+expects `lib.dll` and `lib-1.dll`. on MacOS it expects `liblib.dylib`
+and `liblib.1.dylib`. On other Unices it expects `liblib.so`,
+`liblib.so.1`, and `liblib.so.1.2.3`.
 
-If the `platform` key is present, the installed file entry is only considered if
+If the `platform` key is present, the installed file entry is only
-the platform matches. The following values for `platform` are currently supported:
+considered if the platform matches. The following values for
+`platform` are currently supported:
 
 | platform   | Description                                                          |
 | ---------- | -------------------------------------------------------------------- |
@@ -287,22 +300,25 @@ the platform matches. The following values for `platform` are currently supporte
 
 #### matrix
 
-The `matrix` section can be used to define a test matrix to run project tests
+The `matrix` section can be used to define a test matrix to run
-with different meson options.
+project tests with different meson options.
 
-In the `options` dict, all possible options and their values are specified. Each
+In the `options` dict, all possible options and their values are
-key in the `options` dict is a meson option. It stores a list of all potential
+specified. Each key in the `options` dict is a meson option. It stores
-values in a dict format, which allows to skip specific values based on the current
+a list of all potential values in a dict format, which allows to skip
-environment.
+specific values based on the current environment.
 
-Each value must contain the `val` key for the value of the option. `null` can be
+Each value must contain the `val` key for the value of the option.
-used for adding matrix entries without the current option.
+`null` can be used for adding matrix entries without the current
+option.
 
-Additionally, the `skip_on_env` key can be used to specify a list of environment
+Additionally, the `skip_on_env` key can be used to specify a list of
-variables. If at least one environment variable in `skip_on_env` is present, all
+environment variables. If at least one environment variable in
-matrix entries containing this value are skipped.
+`skip_on_env` is present, all matrix entries containing this value are
+skipped.
 
-Similarly, the `compilers` key can be used to define a mapping of compilers to languages that are required for this value.
+Similarly, the `compilers` key can be used to define a mapping of
+compilers to languages that are required for this value.
 
 ```json
 {
@@ -314,10 +330,11 @@ Similarly, the `compilers` key can be used to define a mapping of compilers to l
 }
 ```
 
-Specific option combinations can be excluded with the `exclude` section. It should
+Specific option combinations can be excluded with the `exclude`
-be noted that `exclude` does not require exact matches. Instead, any matrix entry
+section. It should be noted that `exclude` does not require exact
-containing all option value combinations in `exclude` will be excluded. Thus
+matches. Instead, any matrix entry containing all option value
-an empty dict (`{}`) to will match **all** elements in the test matrix.
+combinations in `exclude` will be excluded. Thus an empty dict (`{}`)
+to will match **all** elements in the test matrix.
 
 The above example will produce the following matrix entries:
 - `opt1=abc`
@@ -334,26 +351,29 @@ Currently supported values are:
 
 #### tools
 
-This section specifies a dict of tool requirements in a simple key-value format.
+This section specifies a dict of tool requirements in a simple
-If a tool is specified, it has to be present in the environment, and the version
+key-value format. If a tool is specified, it has to be present in the
-requirement must be fulfilled. Otherwise, the entire test is skipped (including
+environment, and the version requirement must be fulfilled. Otherwise,
-every element in the test matrix).
+the entire test is skipped (including every element in the test
+matrix).
 
 #### stdout
 
-The `stdout` key contains a list of dicts, describing the expected stdout.
+The `stdout` key contains a list of dicts, describing the expected
+stdout.
 
 Each dict contains the following keys:
 
 - `line`
 - `match` (optional)
 
-Each item in the list is matched, in order, against the remaining actual stdout
+Each item in the list is matched, in order, against the remaining
-lines, after any previous matches. If the actual stdout is exhausted before
+actual stdout lines, after any previous matches. If the actual stdout
-every item in the list is matched, the expected output has not been seen, and
+is exhausted before every item in the list is matched, the expected
-the test has failed.
+output has not been seen, and the test has failed.
 
-The `match` element of the dict determines how the `line` element is matched:
+The `match` element of the dict determines how the `line` element is
+matched:
 
 | Type      | Description             |
 | --------  | ----------------------- |
@@ -362,8 +382,9 @@ The `match` element of the dict determines how the `line` element is matched:
 
 ### Skipping integration tests
 
-Meson uses several continuous integration testing systems that have slightly
+Meson uses several continuous integration testing systems that have
-different interfaces for indicating a commit should be skipped.
+slightly different interfaces for indicating a commit should be
+skipped.
 
 Continuous integration systems currently used:
 - [Azure Pipelines](https://docs.microsoft.com/en-us/azure/devops/pipelines/scripts/git-commands?view=vsts&tabs=yaml#how-do-i-avoid-triggering-a-ci-build-when-the-script-pushes)
@@ -373,7 +394,8 @@ Continuous integration systems currently used:
 
 To promote consistent naming policy, use:
 
-- `[skip ci]` in the commit title if you want to disable all integration tests
+- `[skip ci]` in the commit title if you want to disable all
+  integration tests
 
 ## Documentation
 
@@ -480,7 +502,8 @@ This piece of code would never converge. Every Meson run would change
 the value of the option and thus the output you get out of this build
 definition would be random.
 
-Meson does not permit this by forbidding these sorts of covert channels.
+Meson does not permit this by forbidding these sorts of covert
+channels.
 
 There is one exception to this rule. Users can call into external
 commands with `run_command`. If the output of that command does not

docs/markdown/Creating-Linux-binaries.md

@@ -70,13 +70,12 @@ way.
 You want to embed and statically link every dependency you can
 (especially C++ dependencies). Meson's [Wrap package
 manager](Wrap-dependency-system-manual.md) might be of use here. This
-is equivalent to what you would do on Windows, OSX, Android
+is equivalent to what you would do on Windows, OSX, Android etc.
-etc. Sometimes static linking is not possible. In these cases you need
+Sometimes static linking is not possible. In these cases you need to
-to copy the .so files inside your package. Let's use SDL2 as an
+copy the .so files inside your package. Let's use SDL2 as an example.
-example. First we download and install it as usual giving it our
+First we download and install it as usual giving it our custom install
-custom install prefix (that is, `./configure
+prefix (that is, `./configure --prefix=${HOME}/devroot`). This makes
---prefix=${HOME}/devroot`). This makes Meson's dependency detector
+Meson's dependency detector pick it up automatically.
-pick it up automatically.
 
 ## Building and installing
 

docs/markdown/Creating-releases.md

@@ -24,10 +24,10 @@ ninja dist
 ```
 
 This creates a file called `projectname-version.tar.xz` in the build
-tree subdirectory `meson-dist`. This archive contains the full contents
+tree subdirectory `meson-dist`. This archive contains the full
-of the latest commit in revision control including all the submodules
+contents of the latest commit in revision control including all the
-(recursively). All revision control metadata is removed. Meson then
+submodules (recursively). All revision control metadata is removed.
-takes this archive and tests that it works by doing a full 
+Meson then takes this archive and tests that it works by doing a full
 `compile` + `test` + `install` cycle. If all these pass, Meson will
 then create a `SHA-256` checksum file next to the archive.
 
@@ -36,17 +36,19 @@ then create a `SHA-256` checksum file next to the archive.
 
 Meson behaviour is different from Autotools. The Autotools "dist"
 target packages up the current source tree. Meson packages the latest
-revision control commit. The reason for this is that it prevents developers
+revision control commit. The reason for this is that it prevents
-from doing accidental releases where the distributed archive does not match
+developers from doing accidental releases where the distributed
-any commit in revision control (especially the one tagged for the release).
+archive does not match any commit in revision control (especially the
+one tagged for the release).
 
 
 ## Include subprojects in your release
 
-The `meson dist` command has `--include-subprojects` command line option.
+The `meson dist` command has `--include-subprojects` command line
-When enabled, the source tree of all subprojects used by the current build
+option. When enabled, the source tree of all subprojects used by the
-will also be included in the final tarball. This is useful to distribute
+current build will also be included in the final tarball. This is
-self contained tarball that can be built offline (i.e. `--wrap-mode=nodownload`).
+useful to distribute self contained tarball that can be built offline
+(i.e. `--wrap-mode=nodownload`).
 
 
 ## Skip build and test with `--no-tests`

docs/markdown/Cross-compilation.md

@@ -36,54 +36,54 @@ Let's next look at the most common cross-compilation setup. Let's
 suppose you are on a 64 bit OSX machine and you are cross compiling a
 binary that will run on a 32 bit ARM Linux board. In this case your
 *build machine* is 64 bit OSX, your *host machine* is 32 bit ARM Linux
-and your *target machine* is irrelevant (but defaults to the same value
+and your *target machine* is irrelevant (but defaults to the same
-as the *host machine*). This should be quite understandable as well.
+value as the *host machine*). This should be quite understandable as
+well.
 
-The usual mistake in this case is to call the OSX system the *host* and
+The usual mistake in this case is to call the OSX system the *host*
-the ARM Linux board the *target*. That's because these were their actual
+and the ARM Linux board the *target*. That's because these were their
-names when the cross-compiler itself was compiled!  Let's assume the
+actual names when the cross-compiler itself was compiled! Let's assume
-cross-compiler was created on OSX too. When that happened the *build*
+the cross-compiler was created on OSX too. When that happened the
-and *host machines* were the same OSX and different from the ARM Linux
+*build* and *host machines* were the same OSX and different from the
-*target machine*.
+ARM Linux *target machine*.
 
 In a nutshell, the typical mistake assumes that the terms *build*,
 *host* and *target* refer to some fixed positions whereas they're
 actually relative to where the current compiler is running. Think of
-*host* as a *child* of the current compiler and *target* as an optional
+*host* as a *child* of the current compiler and *target* as an
-*grand-child*. Compilers don't change their terminology when they're
+optional *grand-child*. Compilers don't change their terminology when
-creating another compiler, that would at the very least make their user
+they're creating another compiler, that would at the very least make
-interface much more complex.
+their user interface much more complex.
-
+
-The most complicated case is when you cross-compile a cross
+The most complicated case is when you cross-compile a cross compiler.
-compiler. As an example you can, on a Linux machine, generate a cross
+As an example you can, on a Linux machine, generate a cross compiler
-compiler that runs on Windows but produces binaries on MIPS Linux. In
+that runs on Windows but produces binaries on MIPS Linux. In this case
-this case *build machine* is x86 Linux, *host machine* is x86 Windows
+*build machine* is x86 Linux, *host machine* is x86 Windows and
-and *target machine* is MIPS Linux. This setup is known as the
+*target machine* is MIPS Linux. This setup is known as the [Canadian
-[Canadian
+Cross](https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross).
-Cross](https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross). As
+As a side note, be careful when reading cross compilation articles on
-a side note, be careful when reading cross compilation articles on
 Wikipedia or the net in general. It is very common for them to get
 build, host and target mixed up, even in consecutive sentences, which
 can leave you puzzled until you figure it out.
 
-Again note that when you cross-compile something,
+Again note that when you cross-compile something, the 3 systems
-the 3 systems (*build*, *host*, and *target*) used when
+(*build*, *host*, and *target*) used when building the cross compiler
-building the cross compiler don't align with the ones used when
+don't align with the ones used when building something with that
-building something with that newly-built cross compiler. To take our
+newly-built cross compiler. To take our Canadian Cross scenario from
-Canadian Cross scenario from above (for full generality), since its
+above (for full generality), since its *host machine* is x86 Windows,
-*host machine* is x86 Windows, the *build machine* of anything we
+the *build machine* of anything we build with it is *x86 Windows*. And
-build with it is *x86 Windows*. And since its *target machine* is MIPS
+since its *target machine* is MIPS Linux, the *host machine* of
-Linux, the *host machine* of anything we build with it is *MIPS
+anything we build with it is *MIPS Linux*. Only the *target machine*
-Linux*. Only the *target machine* of whatever we build with it can be
+of whatever we build with it can be freely chosen by us, say if we
-freely chosen by us, say if we want to build another cross compiler
+want to build another cross compiler that runs on MIPS Linux and
-that runs on MIPS Linux and targets Aarch64 iOS. As this example
+targets Aarch64 iOS. As this example hopefully makes clear to you, the
-hopefully makes clear to you, the machine names are relative and
+machine names are relative and shifted over to the left by one
-shifted over to the left by one position.
+position.
 
 If you did not understand all of the details, don't worry. For most
-people it takes a while to wrap their head around these
+people it takes a while to wrap their head around these concepts.
-concepts. Don't panic, it might take a while to click, but you will
+Don't panic, it might take a while to click, but you will get the hang
-get the hang of it eventually.
+of it eventually.
 
 ## Defining the environment
 
@@ -92,8 +92,9 @@ various properties of the cross build environment. The cross file
 consists of different sections.
 
 There are a number of options shared by cross and native files,
-[here](Machine-files.md). It is assumed that you have read that section already,
+[here](Machine-files.md). It is assumed that you have read that
-as this documentation will only call out options specific to cross files.
+section already, as this documentation will only call out options
+specific to cross files.
 
 ### Binaries
 
@@ -102,19 +103,20 @@ as this documentation will only call out options specific to cross files.
 exe_wrapper = 'wine' # A command used to run generated executables.
 ```
 
-The `exe_wrapper` option defines a *wrapper command* that can be used to run
+The `exe_wrapper` option defines a *wrapper command* that can be used
-executables for this host. In this case we can use Wine, which runs Windows
+to run executables for this host. In this case we can use Wine, which
-applications on Linux. Other choices include running the application with
+runs Windows applications on Linux. Other choices include running the
-qemu or a hardware simulator. If you have this kind of a wrapper, these lines
+application with qemu or a hardware simulator. If you have this kind
-are all you need to write. Meson will automatically use the given wrapper
+of a wrapper, these lines are all you need to write. Meson will
-when it needs to run host binaries. This happens e.g. when running the
+automatically use the given wrapper when it needs to run host
-project's test suite.
+binaries. This happens e.g. when running the project's test suite.
 
 ### Properties
 
 In addition to the properties allowed in [all machine
-files](Machine-files.md#properties), the cross file may contain specific
+files](Machine-files.md#properties), the cross file may contain
-information about the cross compiler or the host machine. It looks like this:
+specific information about the cross compiler or the host machine. It
+looks like this:
 
 ```ini
 [properties]
@@ -133,23 +135,24 @@ pkg_config_libdir = '/some/path/lib/pkgconfig'
 ```
 
 In most cases you don't need the size and alignment settings, Meson
-will detect all these by compiling and running some sample
+will detect all these by compiling and running some sample programs.
-programs. If your build requires some piece of data that is not listed
+If your build requires some piece of data that is not listed here,
-here, Meson will stop and write an error message describing how to fix
+Meson will stop and write an error message describing how to fix the
-the issue. If you need extra compiler arguments to be used during
+issue. If you need extra compiler arguments to be used during cross
-cross compilation you can set them with `[langname]_args =
+compilation you can set them with `[langname]_args = [args]`. Just
-[args]`. Just remember to specify the args as an array and not as a
+remember to specify the args as an array and not as a single string
-single string (i.e. not as `'-DCROSS=1 -DSOMETHING=3'`).
+(i.e. not as `'-DCROSS=1 -DSOMETHING=3'`).
-
+
-*Since 0.52.0* The `sys_root` property may point to the root of the host
+*Since 0.52.0* The `sys_root` property may point to the root of the
-system path (the system that will run the compiled binaries). This is used
+host system path (the system that will run the compiled binaries).
-internally by Meson to set the PKG_CONFIG_SYSROOT_DIR environment variable
+This is used internally by Meson to set the PKG_CONFIG_SYSROOT_DIR
-for pkg-config. If this is unset the host system is assumed to share a root
+environment variable for pkg-config. If this is unset the host system
-with the build system.
+is assumed to share a root with the build system.
-
+
-*Since 0.54.0* The pkg_config_libdir property may point to a list of path used
+*Since 0.54.0* The pkg_config_libdir property may point to a list of
-internally by Meson to set the PKG_CONFIG_LIBDIR environment variable for pkg-config.
+path used internally by Meson to set the PKG_CONFIG_LIBDIR environment
-This prevents pkg-config from searching cross dependencies in system directories.
+variable for pkg-config. This prevents pkg-config from searching cross
+dependencies in system directories.
 
 One important thing to note, if you did not define an `exe_wrapper` in
 the previous section, is that Meson will make a best-effort guess at
@@ -191,22 +194,23 @@ These values define the machines sufficiently for cross compilation
 purposes. The corresponding target definition would look the same but
 have `target_machine` in the header. These values are available in
 your Meson scripts. There are three predefined variables called,
-surprisingly, `build_machine`, `host_machine` and
+surprisingly, `build_machine`, `host_machine` and `target_machine`.
-`target_machine`. Determining the operating system of your host
+Determining the operating system of your host machine is simply a
-machine is simply a matter of calling `host_machine.system()`.
+matter of calling `host_machine.system()`.
-
+
-There are two different values for the CPU. The first one is `cpu_family`. It
+There are two different values for the CPU. The first one is
-is a general type of the CPU. This should have a value from [the CPU Family
+`cpu_family`. It is a general type of the CPU. This should have a
-table](Reference-tables.md#cpu-families). *Note* that meson does not add
+value from [the CPU Family table](Reference-tables.md#cpu-families).
-`el` to end cpu_family value for little endian systems. Big endian and little
+*Note* that meson does not add `el` to end cpu_family value for little
-endian mips are both just `mips`, with the `endian` field set approriately.
+endian systems. Big endian and little endian mips are both just
-
+`mips`, with the `endian` field set approriately.
-The second value is `cpu` which is
+
-a more specific subtype for the CPU. Typical values for a `x86` CPU family
+The second value is `cpu` which is a more specific subtype for the
-might include `i386` or `i586` and for `arm` family `armv5` or `armv7hl`.
+CPU. Typical values for a `x86` CPU family might include `i386` or
-Note that CPU type strings are very system dependent. You might get a
+`i586` and for `arm` family `armv5` or `armv7hl`. Note that CPU type
-different value if you check its value on the same machine but with different
+strings are very system dependent. You might get a different value if
-operating systems.
+you check its value on the same machine but with different operating
+systems.
 
 If you do not define your host machine, it is assumed to be the build
 machine. Similarly if you do not specify target machine, it is assumed
@@ -250,8 +254,8 @@ host_int_size  = host_compiler.sizeof('int')
 
 Sometimes you need to build a tool which is used to generate source
 files. These are then compiled for the actual target. For this you
-would want to build some targets with the system's native
+would want to build some targets with the system's native compiler.
-compiler. This requires only one extra keyword argument.
+This requires only one extra keyword argument.
 
 ```meson
 native_exe = executable('mygen', 'mygen.c', native : true)
@@ -292,11 +296,11 @@ c_stdlib = 'mylibc'
 ## Changing cross file settings
 
 Cross file settings are only read when the build directory is set up
-the first time. Any changes to them after the fact will be
+the first time. Any changes to them after the fact will be ignored.
-ignored. This is the same as regular compiles where you can't change
+This is the same as regular compiles where you can't change the
-the compiler once a build tree has been set up. If you need to edit
+compiler once a build tree has been set up. If you need to edit your
-your cross file, then you need to wipe your build tree and recreate it
+cross file, then you need to wipe your build tree and recreate it from
-from scratch.
+scratch.
 
 ## Custom data
 
@@ -317,25 +321,27 @@ myvar = meson.get_cross_property('somekey')
 
 ## Cross file locations
 
-As of version 0.44.0 meson supports loading cross files from system locations
+As of version 0.44.0 meson supports loading cross files from system
-(except on Windows).  This will be $XDG_DATA_DIRS/meson/cross, or if
+locations (except on Windows). This will be
-XDG_DATA_DIRS is undefined, then /usr/local/share/meson/cross and
+$XDG_DATA_DIRS/meson/cross, or if XDG_DATA_DIRS is undefined, then
-/usr/share/meson/cross will be tried in that order, for system wide cross
+/usr/local/share/meson/cross and /usr/share/meson/cross will be tried
-files. User local files can be put in $XDG_DATA_HOME/meson/cross, or
+in that order, for system wide cross files. User local files can be
-~/.local/share/meson/cross if that is undefined.
+put in $XDG_DATA_HOME/meson/cross, or ~/.local/share/meson/cross if
+that is undefined.
 
 The order of locations tried is as follows:
  - A file relative to the local dir
  - The user local location
  - The system wide locations in order
 
-Distributions are encouraged to ship cross files either with
+Distributions are encouraged to ship cross files either with their
-their cross compiler toolchain packages or as a standalone package, and put
+cross compiler toolchain packages or as a standalone package, and put
 them in one of the system paths referenced above.
 
-These files can be loaded automatically without adding a path to the cross
+These files can be loaded automatically without adding a path to the
-file. For example, if a ~/.local/share/meson/cross contains a file called x86-linux,
+cross file. For example, if a ~/.local/share/meson/cross contains a
-then the following command would start a cross build using that cross files:
+file called x86-linux, then the following command would start a cross
+build using that cross files:
 
 ```sh
 meson builddir/ --cross-file x86-linux

docs/markdown/Cuda-module.md

@@ -62,8 +62,9 @@ Multiple architectures and compute capabilities may be passed in using
 - Lists of strings
 - Space (` `), comma (`,`) or semicolon (`;`)-separated strings
 
-The single-word architectural sets `'All'`, `'Common'` or `'Auto'` cannot be
+The single-word architectural sets `'All'`, `'Common'` or `'Auto'`
-mixed with architecture names or compute capabilities. Their interpretation is:
+cannot be mixed with architecture names or compute capabilities. Their
+interpretation is:
 
 | Name              | Compute Capability |
 |-------------------|--------------------|
@@ -162,8 +163,9 @@ This will print
 
     Message: Building for architectures sm30 sm35 sm50 compute50
 
-_Note:_ This function is intended to closely replicate CMake's FindCUDA module function
+_Note:_ This function is intended to closely replicate CMake's
-`CUDA_SELECT_NVCC_ARCH_FLAGS(out_variable, [list of CUDA compute architectures])`
+FindCUDA module function `CUDA_SELECT_NVCC_ARCH_FLAGS(out_variable,
+[list of CUDA compute architectures])`
 
 
 
@@ -174,11 +176,11 @@ _Since: 0.50.0_
 cuda.min_driver_version(cuda_version_string)
 ```
 
-Returns the minimum NVIDIA proprietary driver version required, on the host
+Returns the minimum NVIDIA proprietary driver version required, on the
-system, by kernels compiled with a CUDA Toolkit with the given version string.
+host system, by kernels compiled with a CUDA Toolkit with the given
-
+version string.
-The output of this function is generally intended for informative message
-printing, but could be used for assertions or to conditionally enable
-features known to exist within the minimum NVIDIA driver required.
-
 
+The output of this function is generally intended for informative
+message printing, but could be used for assertions or to conditionally
+enable features known to exist within the minimum NVIDIA driver
+required.

docs/markdown/Custom-build-targets.md

@@ -33,9 +33,9 @@ See [Generating Sources](Generating-sources.md) for more information on this top
 
 Meson only permits you to specify one command to run. This is by
 design as writing shell pipelines into build definition files leads to
-code that is very hard to maintain. If your command requires
+code that is very hard to maintain. If your command requires multiple
-multiple steps you need to write a wrapper script that does all the
+steps you need to write a wrapper script that does all the necessary
-necessary work.
+work.
 
 When doing this you need to be mindful of the following issues:
 

docs/markdown/D.md

@@ -16,14 +16,20 @@ executable('myapp', 'app.d')
 
 ## [Conditional compilation](https://dlang.org/spec/version.html)
 
-If you are using the [version()](https://dlang.org/spec/version.html#version-specification) feature for conditional compilation,
+If you are using the
-you can use it using the `d_module_versions` target property:
+[version()](https://dlang.org/spec/version.html#version-specification)
+feature for conditional compilation, you can use it using the
+`d_module_versions` target property:
+
 ```meson
 project('myapp', 'd')
 executable('myapp', 'app.d', d_module_versions: ['Demo', 'FeatureA'])
 ```
 
-For debugging, [debug()](https://dlang.org/spec/version.html#debug) conditions are compiled automatically in debug builds, and extra identifiers can be added with the `d_debug` argument:
+For debugging, [debug()](https://dlang.org/spec/version.html#debug)
+conditions are compiled automatically in debug builds, and extra
+identifiers can be added with the `d_debug` argument:
+
 ```meson
 project('myapp', 'd')
 executable('myapp', 'app.d', d_debug: [3, 'DebugFeatureA'])
@@ -31,15 +37,15 @@ executable('myapp', 'app.d', d_debug: [3, 'DebugFeatureA'])
 
 ## Using embedded unittests
 
-If you are using embedded [unittest functions](https://dlang.org/spec/unittest.html), your source code needs
+If you are using embedded [unittest
-to be compiled twice, once in regular
+functions](https://dlang.org/spec/unittest.html), your source code
-mode, and once with unittests active. This is done by setting the
+needs to be compiled twice, once in regular mode, and once with
-`d_unittest` target property to `true`.
+unittests active. This is done by setting the `d_unittest` target
-Meson will only ever pass the respective compiler's `-unittest` flag,
+property to `true`. Meson will only ever pass the respective
-and never have the compiler generate an empty main function.
+compiler's `-unittest` flag, and never have the compiler generate an
-If you need that feature in a portable way, create an empty `main()`
+empty main function. If you need that feature in a portable way,
-function for unittests yourself, since the GNU D compiler
+create an empty `main()` function for unittests yourself, since the
-does not have this feature.
+GNU D compiler does not have this feature.
 
 This is an example for using D unittests with Meson:
 ```meson
@@ -87,13 +93,13 @@ install_subdir('src/mylib/', install_dir: 'include/d/mylib/')
 ```
 
 It is important to make the D sources install in a subdirectory in the
- include path, in this case `/usr/include/d/mylib/mylib`.
+include path, in this case `/usr/include/d/mylib/mylib`. All D
-All D compilers include the `/usr/include/d` directory by default, and
+compilers include the `/usr/include/d` directory by default, and if
- if your library would be installed into `/usr/include/d/mylib`, there
+your library would be installed into `/usr/include/d/mylib`, there is
-is a high chance that, when you compile your project again on a
+a high chance that, when you compile your project again on a machine
-machine where you installed it, the compiler will prefer the old
+where you installed it, the compiler will prefer the old installed
-installed include over the new version in the source tree, leading to
+include over the new version in the source tree, leading to very
-very confusing errors.
+confusing errors.
 
 This is an example of how to use the D library we just built and
 installed in an application:
@@ -113,7 +119,9 @@ compilers will lead to problems.
 # Integrating with DUB
 
 DUB is a fully integrated build system for D, but it is also a way to
-provide dependencies. Adding dependencies from the [D package registry](https://code.dlang.org/)
+provide dependencies. Adding dependencies from the [D package
-is pretty straight forward. You can find how to do this in
+registry](https://code.dlang.org/) is pretty straight forward. You can
-[Dependencies](Dependencies.md#some-notes-on-dub). You can also automatically
+find how to do this in
-generate a `dub.json` file as explained in [Dlang](Dlang-module.md#generate_dub_file).
+[Dependencies](Dependencies.md#some-notes-on-dub). You can also
+automatically generate a `dub.json` file as explained in
+[Dlang](Dlang-module.md#generate_dub_file).

docs/markdown/Dependencies.md

@@ -69,10 +69,10 @@ page](#dependencies-with-custom-lookup-functionality).
 *Note* new in 0.51.0
 *new in 0.54.0, the `internal` keyword*
 
-When you need to get an arbitrary variables from a dependency that can be
+When you need to get an arbitrary variables from a dependency that can
-found multiple ways and you don't want to constrain the type you can use
+be found multiple ways and you don't want to constrain the type you
-the generic `get_variable` method. This currently supports cmake, pkg-config,
+can use the generic `get_variable` method. This currently supports
-and config-tool based variables.
+cmake, pkg-config, and config-tool based variables.
 
 ```meson
 foo_dep = dependency('foo')
@@ -80,14 +80,15 @@ var = foo_dep.get_variable(cmake : 'CMAKE_VAR', pkgconfig : 'pkg-config-var', co
 ```
 
 It accepts the keywords 'cmake', 'pkgconfig', 'pkgconfig_define',
-'configtool', 'internal', and 'default_value'. 'pkgconfig_define' works just
+'configtool', 'internal', and 'default_value'. 'pkgconfig_define'
-like the 'define_variable' argument to `get_pkgconfig_variable`. When this
+works just like the 'define_variable' argument to
-method is invoked the keyword corresponding to the underlying type of the
+`get_pkgconfig_variable`. When this method is invoked the keyword
-dependency will be used to look for a variable. If that variable cannot be
+corresponding to the underlying type of the dependency will be used to
-found or if the caller does not provide an argument for the type of
+look for a variable. If that variable cannot be found or if the caller
-dependency, one of the following will happen: If 'default_value' was provided
+does not provide an argument for the type of dependency, one of the
-that value will be returned, if 'default_value' was not provided then an
+following will happen: If 'default_value' was provided that value will
-error will be raised.
+be returned, if 'default_value' was not provided then an error will be
+raised.
 
 # Declaring your own
 
@@ -130,8 +131,8 @@ What this declaration means is that first Meson tries to look up the
 dependency from the system (such as by using pkg-config). If it is not
 available, then it builds subproject named `foo` and from that
 extracts a variable `foo_dep`. That means that the return value of
-this function is either an external or an internal dependency
+this function is either an external or an internal dependency object.
-object. Since they can be used interchangeably, the rest of the build
+Since they can be used interchangeably, the rest of the build
 definitions do not need to care which one it is. Meson will take care
 of all the work behind the scenes to make this work.
 
@@ -156,14 +157,14 @@ The dependency method order for `auto` is:
 
 Meson can use the CMake `find_package()` function to detect
 dependencies with the builtin `Find<NAME>.cmake` modules and exported
-project configurations (usually in `/usr/lib/cmake`). Meson is able
+project configurations (usually in `/usr/lib/cmake`). Meson is able to
-to use both the old-style `<NAME>_LIBRARIES` variables as well as
+use both the old-style `<NAME>_LIBRARIES` variables as well as
 imported targets.
 
 It is possible to manually specify a list of CMake targets that should
 be used with the `modules` property. However, this step is optional
-since meson tries to automatically guess the correct target based on the
+since meson tries to automatically guess the correct target based on
-name of the dependency.
+the name of the dependency.
 
 Depending on the dependency it may be necessary to explicitly specify
 a CMake target with the `modules` property if meson is unable to guess
@@ -173,22 +174,25 @@ it automatically.
     cmake_dep = dependency('ZLIB', method : 'cmake', modules : ['ZLIB::ZLIB'])
 ```
 
-Support for adding additional `COMPONENTS` for the CMake `find_package` lookup
+Support for adding additional `COMPONENTS` for the CMake
-is provided with the `components` kwarg (*introduced in 0.54.0*). All specified
+`find_package` lookup is provided with the `components` kwarg
-componets will be passed directly to `find_package(COMPONENTS)`.
+(*introduced in 0.54.0*). All specified componets will be passed
+directly to `find_package(COMPONENTS)`.
 
 Support for packages which require a specified version for CMake
-`find_package` to succeed is provided with the `cmake_package_version` kwarg
+`find_package` to succeed is provided with the `cmake_package_version`
-(*introduced in 0.57.0*). The specified `cmake_package_version` will be
+kwarg (*introduced in 0.57.0*). The specified `cmake_package_version`
-passed directly as the second parameter to `find_package`.
+will be passed directly as the second parameter to `find_package`.
 
-It is also possible to reuse existing `Find<name>.cmake` files with the
+It is also possible to reuse existing `Find<name>.cmake` files with
-`cmake_module_path` property. Using this property is equivalent to setting the
+the `cmake_module_path` property. Using this property is equivalent to
-`CMAKE_MODULE_PATH` variable in CMake. The path(s) given to `cmake_module_path`
+setting the `CMAKE_MODULE_PATH` variable in CMake. The path(s) given
-should all be relative to the project source directory. Absolute paths
+to `cmake_module_path` should all be relative to the project source
-should only be used if the CMake files are not stored in the project itself.
+directory. Absolute paths should only be used if the CMake files are
+not stored in the project itself.
 
-Additional CMake parameters can be specified with the `cmake_args` property.
+Additional CMake parameters can be specified with the `cmake_args`
+property.
 
 ## Dub
 
@@ -216,15 +220,16 @@ DC="dmd" meson builddir
 Some dependencies have specific detection logic.
 
 Generic dependency names are case-sensitive<sup>[1](#footnote1)</sup>,
-but these dependency names are matched case-insensitively.  The
+but these dependency names are matched case-insensitively. The
 recommended style is to write them in all lower-case.
 
-In some cases, more than one detection method exists, and the `method` keyword
+In some cases, more than one detection method exists, and the `method`
-may be used to select a detection method to use.  The `auto` method uses any
+keyword may be used to select a detection method to use. The `auto`
-checking mechanisms in whatever order meson thinks is best.
+method uses any checking mechanisms in whatever order meson thinks is
+best.
 
-e.g. libwmf and CUPS provide both pkg-config and config-tool support. You can
+e.g. libwmf and CUPS provide both pkg-config and config-tool support.
-force one or another via the `method` keyword:
+You can force one or another via the `method` keyword:
 
 ```meson
 cups_dep = dependency('cups', method : 'pkg-config')
@@ -247,8 +252,9 @@ libgcrypt_dep = dependency('libgcrypt', version: '>= 1.8')
 gpgme_dep = dependency('gpgme', version: '>= 1.0')
 ```
 
-*Since 0.55.0* Meson won't search $PATH any more for a config tool binary when
+*Since 0.55.0* Meson won't search $PATH any more for a config tool
-cross compiling if the config tool did not have an entry in the cross file.
+binary when cross compiling if the config tool did not have an entry
+in the cross file.
 
 ## AppleFrameworks
 
@@ -293,12 +299,12 @@ You can call `dependency` multiple times with different modules and
 use those to link against your targets.
 
 If your boost headers or libraries are in non-standard locations you
-can set the `BOOST_ROOT`, or the `BOOST_INCLUDEDIR` and `BOOST_LIBRARYDIR`
+can set the `BOOST_ROOT`, or the `BOOST_INCLUDEDIR` and
-environment variables. *(added in 0.56.0)* You can also set these
+`BOOST_LIBRARYDIR` environment variables. *(added in 0.56.0)* You can
-parameters as `boost_root`, `boost_include`, and `boost_librarydir` in your
+also set these parameters as `boost_root`, `boost_include`, and
-native or cross machine file. Note that machine file variables are
+`boost_librarydir` in your native or cross machine file. Note that
-preferred to environment variables, and that specifying any of these
+machine file variables are preferred to environment variables, and
-disables system-wide search for boost.
+that specifying any of these disables system-wide search for boost.
 
 You can set the argument `threading` to `single` to use boost
 libraries that have been compiled for single-threaded use instead.
@@ -367,12 +373,15 @@ language-specific, you must specify the requested language using the
  * `dependency('hdf5', language: 'cpp')` for the C++ HDF5 headers and libraries
  * `dependency('hdf5', language: 'fortran')` for the Fortran HDF5 headers and libraries
 
-Meson uses pkg-config to find HDF5. The standard low-level HDF5 function and the `HL` high-level HDF5 functions are linked for each language.
+Meson uses pkg-config to find HDF5. The standard low-level HDF5
+function and the `HL` high-level HDF5 functions are linked for each
+language.
 
 `method` may be `auto`, `config-tool` or `pkg-config`.
 
 *New in 0.56.0* the `config-tool` method.
-*New in 0.56.0* the dependencies now return proper dependency types and `get_variable` and similar methods should work as expected.
+*New in 0.56.0* the dependencies now return proper dependency types
+ and `get_variable` and similar methods should work as expected.
 
 ## libwmf
 
@@ -382,13 +391,13 @@ Meson uses pkg-config to find HDF5. The standard low-level HDF5 function and the
 
 ## LLVM
 
-Meson has native support for LLVM going back to version LLVM version 3.5.
+Meson has native support for LLVM going back to version LLVM version
-It supports a few additional features compared to other config-tool based
+3.5. It supports a few additional features compared to other
-dependencies.
+config-tool based dependencies.
 
-As of 0.44.0 Meson supports the `static` keyword argument for
+As of 0.44.0 Meson supports the `static` keyword argument for LLVM.
-LLVM. Before this LLVM >= 3.9 would always dynamically link, while
+Before this LLVM >= 3.9 would always dynamically link, while older
-older versions would statically link, due to a quirk in `llvm-config`.
+versions would statically link, due to a quirk in `llvm-config`.
 
 `method` may be `auto`, `config-tool`, or `cmake`.
 
@@ -412,10 +421,13 @@ llvm_dep = dependency(
 ```
 
 ### Using LLVM tools
-When using LLVM as library but also needing its tools, it is often beneficial to use the same version.
+
-This can partially be achieved with the `version` argument of `find_program()`.
+When using LLVM as library but also needing its tools, it is often
-However, distributions tend to package different LLVM versions in rather different ways.
+beneficial to use the same version. This can partially be achieved
-Therefore, it is often better to use the llvm dependency directly to retrieve the tools:
+with the `version` argument of `find_program()`. However,
+distributions tend to package different LLVM versions in rather
+different ways. Therefore, it is often better to use the llvm
+dependency directly to retrieve the tools:
 
 ```meson
 llvm_dep = dependency('llvm', version : ['>= 8', '< 9'])
@@ -495,9 +507,9 @@ Python3 is handled specially by meson:
     - On Windows the fallback is the current `python3` interpreter.
     - On OSX the fallback is a framework dependency from `/Library/Frameworks`.
 
-Note that `python3` found by this dependency might differ from the one used in
+Note that `python3` found by this dependency might differ from the one
-`python3` module because modules uses the current interpreter, but dependency tries
+used in `python3` module because modules uses the current interpreter,
-`pkg-config` first.
+but dependency tries `pkg-config` first.
 
 `method` may be `auto`, `extraframework`, `pkg-config` or `sysconfig`
 
@@ -534,42 +546,46 @@ the list of sources for the target. The `modules` keyword of
 `dependency` works just like it does with Boost. It tells which
 subparts of Qt the program uses.
 
-You can set the `main` keyword argument to `true` to use the `WinMain()`
+You can set the `main` keyword argument to `true` to use the
-function provided by qtmain static library (this argument does nothing on platforms
+`WinMain()` function provided by qtmain static library (this argument
-other than Windows).
+does nothing on platforms other than Windows).
 
-Setting the optional `private_headers` keyword to true adds the private header
+Setting the optional `private_headers` keyword to true adds the
-include path of the given module(s) to the compiler flags.  (since v0.47.0)
+private header include path of the given module(s) to the compiler
+flags. (since v0.47.0)
 
-**Note** using private headers in your project is a bad idea, do so at your own
+**Note** using private headers in your project is a bad idea, do so at
-risk.
+your own risk.
 
 `method` may be `auto`, `pkg-config` or `qmake`.
 
 ## SDL2
 
-SDL2 can be located using `pkg-confg`, the `sdl2-config` config tool, or as an
+SDL2 can be located using `pkg-confg`, the `sdl2-config` config tool,
-OSX framework.
+or as an OSX framework.
 
-`method` may be `auto`, `config-tool`, `extraframework` or `pkg-config`.
+`method` may be `auto`, `config-tool`, `extraframework` or
+`pkg-config`.
 
 ## Threads
 
-This dependency selects the appropriate compiler flags and/or libraries to use
+This dependency selects the appropriate compiler flags and/or
-for thread support.
+libraries to use for thread support.
 
 See [threads](Threads.md).
 
 ## Valgrind
 
-Meson will find valgrind using `pkg-config`, but only uses the compilation flags
+Meson will find valgrind using `pkg-config`, but only uses the
-and avoids trying to link with it's non-PIC static libs.
+compilation flags and avoids trying to link with it's non-PIC static
+libs.
 
 ## Vulkan
 
 *(added 0.42.0)*
 
-Vulkan can be located using `pkg-config`, or the `VULKAN_SDK` environment variable.
+Vulkan can be located using `pkg-config`, or the `VULKAN_SDK`
+environment variable.
 
 `method` may be `auto`, `pkg-config` or `system`.
 
@@ -601,20 +617,22 @@ $ wx-config --libs std stc
 
 *(added 0.51.0)*
 
-Shaderc currently does not ship with any means of detection. Nevertheless, Meson
+Shaderc currently does not ship with any means of detection.
-can try to detect it using `pkg-config`, but will default to looking for the
+Nevertheless, Meson can try to detect it using `pkg-config`, but will
-appropriate library manually. If the `static` keyword argument is `true`,
+default to looking for the appropriate library manually. If the
-`shaderc_combined` is preferred. Otherwise, `shaderc_shared` is preferred. Note
+`static` keyword argument is `true`, `shaderc_combined` is preferred.
-that it is not possible to obtain the shaderc version using this method.
+Otherwise, `shaderc_shared` is preferred. Note that it is not possible
+to obtain the shaderc version using this method.
 
 `method` may be `auto`, `pkg-config` or `system`.
 
 ## Zlib
 
-Zlib ships with pkg-config and cmake support, but on some operating systems
+Zlib ships with pkg-config and cmake support, but on some operating
-(windows, macOs, FreeBSD, dragonflybsd), it is provided as part of the base
+systems (windows, macOs, FreeBSD, dragonflybsd), it is provided as
-operating system without pkg-config support. The new System finder can be used
+part of the base operating system without pkg-config support. The new
-on these OSes to link with the bundled version.
+System finder can be used on these OSes to link with the bundled
+version.
 
 `method` may be `auto`, `pkg-config`, `cmake`, or `system`.
 
@@ -624,9 +642,9 @@ on these OSes to link with the bundled version.
 
 *(Since 0.54.0)*
 
-Curses (and ncurses) are a cross platform pain in the butt. Meson wraps up
+Curses (and ncurses) are a cross platform pain in the butt. Meson
-these dependencies in the `curses` dependency. This covers both `ncurses`
+wraps up these dependencies in the `curses` dependency. This covers
-(preferred) and other curses implementations.
+both `ncurses` (preferred) and other curses implementations.
 
 `method` may be `auto`, `pkg-config`, `config-tool`, or `system`.
 

docs/markdown/Design-rationale.md

@@ -2,7 +2,8 @@
 title: Design rationale
 ...
 
-This is the original design rationale for Meson. The syntax it describes does not match the released version
+This is the original design rationale for Meson. The syntax it
+describes does not match the released version
 ==
 
 A software developer's most important tool is the editor. If you talk
@@ -65,7 +66,8 @@ what would it take to build a "good" build system. What kind of syntax
 would suit this problem? What sort of problems would this application
 need to solve? What sort of solutions would be the most appropriate?
 
-To get things started, here is a list of requirements any modern cross-platform build system needs to provide.
+To get things started, here is a list of requirements any modern
+cross-platform build system needs to provide.
 
 ### 1. Must be simple to use
 
@@ -174,7 +176,8 @@ examples we would like to emphasize that this is not in any way the
 final code. It is proof of concept code that works in the system as it
 currently exists (February 2013), but may change at any time.
 
-Let's start simple. Here is the code to compile a single executable binary.
+Let's start simple. Here is the code to compile a single executable
+binary.
 
 ```meson
 project('compile one', 'c')

docs/markdown/Dlang-module.md

@@ -40,4 +40,5 @@ initial one. The module will only update the values specified in
 `generate_dub_file()`.
 
 Although not required, you will need to have a `description` and
-`license` if you want to publish the package in the [D package registry](https://code.dlang.org/).
+`license` if you want to publish the package in the [D package
+registry](https://code.dlang.org/).

docs/markdown/External-Project-module.md

@@ -5,21 +5,24 @@
 
 *This is an experimental module, API could change.*
 
-This module allows building code that uses build systems other than Meson. This
+This module allows building code that uses build systems other than
-module is intended to be used to build Autotools subprojects as fallback if the
+Meson. This module is intended to be used to build Autotools
-dependency couldn't be found on the system (e.g. too old distro version).
+subprojects as fallback if the dependency couldn't be found on the
-
+system (e.g. too old distro version).
-The project will be compiled out-of-tree inside Meson's build directory. The
+
-project will also be installed inside Meson's build directory using make's
+The project will be compiled out-of-tree inside Meson's build
+directory. The project will also be installed inside Meson's build
+directory using make's
 [`DESTDIR`](https://www.gnu.org/prep/standards/html_node/DESTDIR.html)
-feature. During project installation step, that DESTDIR will be copied verbatim
+feature. During project installation step, that DESTDIR will be copied
-into the desired location.
+verbatim into the desired location.
 
-External subprojects can use libraries built by Meson (main project, or other
+External subprojects can use libraries built by Meson (main project,
-subprojects) using pkg-config, thanks to `*-uninstalled.pc` files generated by
+or other subprojects) using pkg-config, thanks to `*-uninstalled.pc`
-[`pkg.generate()`](Pkgconfig-module.md).
+files generated by [`pkg.generate()`](Pkgconfig-module.md).
 
 External build system requirements:
+
 - Must support out-of-tree build. The configure script will be invoked with the
   current workdir inside Meson's build directory and not subproject's top source
   directory.
@@ -31,6 +34,7 @@ External build system requirements:
   transparently.
 
 Known limitations:
+
 - Executables from external projects cannot be used uninstalled, because they
   would need its libraries to be installed in the final location. This is why
   there is no `find_program()` method.
@@ -49,17 +53,18 @@ Known limitations:
 
 ### `add_project()`
 
-This function should be called at the root directory of a project using another
+This function should be called at the root directory of a project
-build system. Usually in a `meson.build` file placed in the top directory of a
+using another build system. Usually in a `meson.build` file placed in
-subproject, but could be also in any subdir.
+the top directory of a subproject, but could be also in any subdir.
 
-Its first positional argument is the name of the configure script to be
+Its first positional argument is the name of the configure script to
-executed (e.g. `configure`), that file must be in the current directory and
+be executed (e.g. `configure`), that file must be in the current
-executable. Note that if a bootstrap script is required (e.g. `autogen.sh` when
+directory and executable. Note that if a bootstrap script is required
-building from git instead of tarball), it can be done using `run_command()`
+(e.g. `autogen.sh` when building from git instead of tarball), it can
-before calling `add_project()` method.
+be done using `run_command()` before calling `add_project()` method.
 
 Keyword arguments:
+
 - `configure_options`: An array of strings to be passed as arguments to the
   configure script. Some special tags will be replaced by Meson before passing
   them to the configure script: `@PREFIX@`, `@LIBDIR@` and `@INCLUDEDIR@`.
@@ -115,8 +120,9 @@ mylib_dep = p.dependency('mylib')
 
 ## Using wrap file
 
-Most of the time the project will be built as a subproject, and fetched using
+Most of the time the project will be built as a subproject, and
-a `.wrap` file. In that case the simple `meson.build` file needed to build the
+fetched using a `.wrap` file. In that case the simple `meson.build`
-subproject can be provided by adding `patch_directory=mysubproject` line
+file needed to build the subproject can be provided by adding
-in the wrap file, and place the build definition file at
+`patch_directory=mysubproject` line in the wrap file, and place the
+build definition file at
 `subprojects/packagefiles/mysubproject/meson.build`.

docs/markdown/External-commands.md

@@ -33,14 +33,14 @@ run_command('command', 'arg1', 'arg2', env: env)
 
 The `run_command` function returns an object that can be queried for
 return value and text written to stdout and stderr. The `strip` method
-call is used to strip trailing and leading whitespace from
+call is used to strip trailing and leading whitespace from strings.
-strings. Usually output from command line programs ends in a newline,
+Usually output from command line programs ends in a newline, which is
-which is unwanted in string variables. The first argument can be
+unwanted in string variables. The first argument can be either a
-either a string or an executable you have detected earlier with
+string or an executable you have detected earlier with `find_program`.
-`find_program`.
 
 Meson will autodetect scripts with a shebang line and run them with
-the executable/interpreter specified in it both on Windows and on Unixes.
+the executable/interpreter specified in it both on Windows and on
+Unixes.
 
 Note that you can not pass your command line as a single string. That
 is, calling `run_command('do_something foo bar')` will not work. You

docs/markdown/FAQ.md

@@ -61,10 +61,10 @@ Instead of specifying files explicitly, people seem to want to do this:
 executable('myprog', sources : '*.cpp') # This does NOT work!
 ```
 
-Meson does not support this syntax and the reason for this is
+Meson does not support this syntax and the reason for this is simple.
-simple. This can not be made both reliable and fast. By reliable we
+This can not be made both reliable and fast. By reliable we mean that
-mean that if the user adds a new source file to the subdirectory,
+if the user adds a new source file to the subdirectory, Meson should
-Meson should detect that and make it part of the build automatically.
+detect that and make it part of the build automatically.
 
 One of the main requirements of Meson is that it must be fast. This
 means that a no-op build in a tree of 10 000 source files must take no
@@ -396,12 +396,14 @@ advantages:
    so specifying `libfoo.a` instead of `foo.lib` does not change the workflow,
    and is an improvement since it's less ambiguous.
 
-If, for some reason, you really need your project to output static libraries of
+If, for some reason, you really need your project to output static
-the form `foo.lib` when building with MSVC, you can set the
+libraries of the form `foo.lib` when building with MSVC, you can set
+the
 [`name_prefix:`](https://mesonbuild.com/Reference-manual.html#library)
-kwarg to `''` and the [`name_suffix:`](https://mesonbuild.com/Reference-manual.html#library)
+kwarg to `''` and the
-kwarg to `'lib'`. To get the default behaviour for each, you can either not
+[`name_suffix:`](https://mesonbuild.com/Reference-manual.html#library)
-specify the kwarg, or pass `[]` (an empty array) to it.
+kwarg to `'lib'`. To get the default behaviour for each, you can
+either not specify the kwarg, or pass `[]` (an empty array) to it.
 
 ## Do I need to add my headers to the sources list like in Autotools?
 

docs/markdown/Fs-module.md

@@ -72,11 +72,12 @@ The `fs.size(filename)` method returns the size of the file in integer bytes.
 
 ### is_samepath
 
-The `fs.is_samepath(path1, path2)` returns boolean `true` if both paths resolve to the same path.
+The `fs.is_samepath(path1, path2)` returns boolean `true` if both
-For example, suppose path1 is a symlink and path2 is a relative path.
+paths resolve to the same path. For example, suppose path1 is a
-If path1 can be resolved to path2, then `true` is returned.
+symlink and path2 is a relative path. If `path1` can be resolved to
-If path1 is not resolved to path2, `false` is returned.
+`path2`, then `true` is returned. If `path1` is not resolved to
-If path1 or path2 do not exist, `false` is returned.
+`path2`, `false` is returned. If `path1` or `path2` do not exist,
+`false` is returned.
 
 Examples:
 
@@ -102,13 +103,15 @@ fs.is_samepath(p, s)  # false
 
 ## Filename modification
 
-The files need not actually exist yet for these path string manipulation methods.
+The files need not actually exist yet for these path string
+manipulation methods.
 
 ### expanduser
 
 *since 0.54.0*
 
-A path string with a leading `~` is expanded to the user home directory
+A path string with a leading `~` is expanded to the user home
+directory
 
 Examples:
 
@@ -122,8 +125,9 @@ fs.expanduser('~/foo')  # <homedir>/foo
 
 *since 0.54.0*
 
-`fs.as_posix(path)` assumes a Windows path, even if on a Unix-like system.
+`fs.as_posix(path)` assumes a Windows path, even if on a Unix-like
-Thus, all `'\'` or `'\\'` are turned to '/', even if you meant to escape a character.
+system. Thus, all `'\'` or `'\\'` are turned to '/', even if you meant
+to escape a character.
 
 Examples
 
@@ -136,8 +140,8 @@ fs.as_posix('foo\\bar/baz') == 'foo/bar/baz'  # true
 
 ### replace_suffix
 
-The `replace_suffix` method is a *string manipulation* convenient for filename modifications.
+The `replace_suffix` method is a *string manipulation* convenient for
-It allows changing the filename suffix like:
+filename modifications. It allows changing the filename suffix like:
 
 #### swap suffix
 
@@ -188,7 +192,8 @@ fs.name('foo/bar/baz.dll.a')  # baz.dll.a
 
 *since 0.54.0*
 
-Returns the last component of the path, dropping the last part of the suffix
+Returns the last component of the path, dropping the last part of the
+suffix
 
 ```meson
 fs.stem('foo/bar/baz.dll')  # baz

docs/markdown/Generating-sources.md

@@ -48,8 +48,9 @@ Then you just put that in your program and you're done.
 
 ### Generating headers
 
-Adding a generated header to a source list will ensure that the header is
+Adding a generated header to a source list will ensure that the header
-generated and that the proper include paths are created for the target:
+is generated and that the proper include paths are created for the
+target:
 
 ```meson
 prog_python = import('python').find_installation('python3')
@@ -73,18 +74,19 @@ libfoo = static_library('foo', [foo_c, foo_h])
 executable('myexe', ['main.c', foo_h], link_with : libfoo)
 ```
 
-Each target that depends on a generated header should add that header to it's sources,
+Each target that depends on a generated header should add that header
-as seen above with `libfoo` and `myexe`. This is because there is no way for
+to it's sources, as seen above with `libfoo` and `myexe`. This is
-meson or the backend to know that `myexe` depends on `foo.h` just because
+because there is no way for meson or the backend to know that `myexe`
-`libfoo` does, it could be a private header.
+depends on `foo.h` just because `libfoo` does, it could be a private
+header.
 
 ### Generating multiple files at a time
 
-Sometimes it makes sense for a single generator to create two or more files at
+Sometimes it makes sense for a single generator to create two or more
-a time, (perhaps a header and source file), meson has this case covered as
+files at a time, (perhaps a header and source file), meson has this
-well. `custom_target`s can be indexed like a list to get each output file
+case covered as well. `custom_target`s can be indexed like a list to
-separately. The order is the same as the order of the output argument to
+get each output file separately. The order is the same as the order of
-`custom_target`
+the output argument to `custom_target`
 
 ```meson
 prog_python = import('python').find_installation('python3')
@@ -101,13 +103,14 @@ libfoo = static_library('foo', [foo_ch])
 executable('myexe', ['main.c', foo_ch[1]], link_with : libfoo)
 ```
 
-In this case `libfoo` depends on both `foo.c` and `foo.h` but `myexe` only
+In this case `libfoo` depends on both `foo.c` and `foo.h` but `myexe`
-depends on `foo.h`, the second output.
+only depends on `foo.h`, the second output.
 
 ### Using dependencies to manage generated resources
 
-In some cases it might be easier to use `declare_dependency` to "bundle" the header
+In some cases it might be easier to use `declare_dependency` to
-and library dependency, especially if there are many generated headers:
+"bundle" the header and library dependency, especially if there are
+many generated headers:
 
 ```meson
 idep_foo = declare_dependency(
@@ -117,7 +120,8 @@ idep_foo = declare_dependency(
 ```
 
 See [dependencies](Dependencies.md#declaring-your-own), and
-[reference](Reference-manual.md#declare_dependency) for more information.
+[reference](Reference-manual.md#declare_dependency) for more
+information.
 
 ## Using generator()
 

docs/markdown/Gnome-module.md

@@ -3,7 +3,7 @@
 This module provides helper tools for build operations needed when
 building Gnome/GLib programs.
 
-**Note**: the compilation commands here might not work properly when
+**Note**: the compilation commands here might not work properly when
   you change the source files. This is a bug in the respective
   compilers which do not expose the required dependency
   information. This has been reported upstream in [this bug]. Until
@@ -128,9 +128,9 @@ Returns an array of two elements which are: `[c_source, header_file]`
 ### gnome.mkenums()
 
 Generates enum files for GObject using the `glib-mkenums` tool. The
-first argument is the base name of the output files, unless `c_template`
+first argument is the base name of the output files, unless
-and `h_template` are specified. In this case, the output files will be
+`c_template` and `h_template` are specified. In this case, the output
-the base name of the values passed as templates.
+files will be the base name of the values passed as templates.
 
 This method is essentially a wrapper around the `glib-mkenums` tool's
 command line API. It is the most featureful method for enum creation.
@@ -252,14 +252,14 @@ one XML file.
   bundle depending on previous options
 * `install_header`: (*Added 0.46.0*) if true, install the header file
 
-Starting *0.46.0*, this function returns a list of at least two custom targets
+Starting *0.46.0*, this function returns a list of at least two custom
-(in order): one for the source code and one for the header. The list will
+targets (in order): one for the source code and one for the header.
-contain a third custom target for the generated docbook files if that keyword
+The list will contain a third custom target for the generated docbook
-argument is passed.
+files if that keyword argument is passed.
 
-Earlier versions return a single custom target representing all the outputs.
+Earlier versions return a single custom target representing all the
-Generally, you should just add this list of targets to a top level target's
+outputs. Generally, you should just add this list of targets to a top
-source list.
+level target's source list.
 
 Example:
 
@@ -344,11 +344,12 @@ of the module.
   Note that this has the downside of rebuilding the doc for each build, which is
   often very slow. It usually should be enabled only in CI.
 
-This also creates a `$module-doc` target that can be run to build documentation.
+This also creates a `$module-doc` target that can be run to build
-Normally the documentation is only built on install.
+documentation. Normally the documentation is only built on install.
 
-*Since 0.52.0* Returns a target object that can be passed as dependency to other
+*Since 0.52.0* Returns a target object that can be passed as
-targets using generated doc files (e.g. in `content_files` of another doc).
+dependency to other targets using generated doc files (e.g. in
+`content_files` of another doc).
 
 ### gnome.gtkdoc_html_dir()
 

docs/markdown/IDE-integration.md

@@ -4,29 +4,31 @@ short-description: Meson's API to integrate Meson support into an IDE
 
 # IDE integration
 
-Meson has exporters for Visual Studio and XCode, but writing a custom backend
+Meson has exporters for Visual Studio and XCode, but writing a custom
-for every IDE out there is not a scalable approach. To solve this problem,
+backend for every IDE out there is not a scalable approach. To solve
-Meson provides an API that makes it easy for any IDE or build tools to
+this problem, Meson provides an API that makes it easy for any IDE or
-integrate Meson builds and provide an experience comparable to a solution
+build tools to integrate Meson builds and provide an experience
-native to the IDE.
+comparable to a solution native to the IDE.
 
 All the resources required for such a IDE integration can be found in
 the `meson-info` directory in the build directory.
 
-The first thing to do when setting up a Meson project in an IDE is to select
+The first thing to do when setting up a Meson project in an IDE is to
-the source and build directories. For this example we assume that the source
+select the source and build directories. For this example we assume
-resides in an Eclipse-like directory called `workspace/project` and the build
+that the source resides in an Eclipse-like directory called
-tree is nested inside it as `workspace/project/build`. First, we initialize
+`workspace/project` and the build tree is nested inside it as
-Meson by running the following command in the source directory.
+`workspace/project/build`. First, we initialize Meson by running the
+following command in the source directory.
 
     meson builddir
 
 With this command meson will configure the project and also generate
-introspection information that is stored in `intro-*.json` files in the
+introspection information that is stored in `intro-*.json` files in
-`meson-info` directory. The introspection dump will be automatically updated
+the `meson-info` directory. The introspection dump will be
-when meson is (re)configured, or the build options change. Thus, an IDE can
+automatically updated when meson is (re)configured, or the build
-watch for changes in this directory to know when something changed. Note that
+options change. Thus, an IDE can watch for changes in this directory
-`meson-info.json` guaranteed to be the last file written.
+to know when something changed. Note that `meson-info.json` guaranteed
+to be the last file written.
 
 The `meson-info` directory should contain the following files:
 
@@ -41,13 +43,14 @@ The `meson-info` directory should contain the following files:
 | `intro-targets.json`           | Full list of all build targets                                      |
 | `intro-tests.json`             | Lists all tests with instructions how to run them                   |
 
-The content of the JSON files is further specified in the remainder of this document.
+The content of the JSON files is further specified in the remainder of
+this document.
 
 ## The `targets` section
 
-The most important file for an IDE is probably `intro-targets.json`. Here each
+The most important file for an IDE is probably `intro-targets.json`.
-target with its sources and compiler parameters is specified. The JSON format
+Here each target with its sources and compiler parameters is
-for one target is defined as follows:
+specified. The JSON format for one target is defined as follows:
 
 ```json
 {
@@ -64,25 +67,27 @@ for one target is defined as follows:
 }
 ```
 
-If the key `installed` is set to `true`, the key `install_filename` will also
+If the key `installed` is set to `true`, the key `install_filename`
-be present. It stores the installation location for each file in `filename`.
+will also be present. It stores the installation location for each
-If one file in `filename` is not installed, its corresponding install location
+file in `filename`. If one file in `filename` is not installed, its
-is set to `null`.
+corresponding install location is set to `null`.
 
-The `subproject` key specifies the name of the subproject this target was
+The `subproject` key specifies the name of the subproject this target
-defined in, or `null` if the target was defined in the top level project.
+was defined in, or `null` if the target was defined in the top level
+project.
 
-*(New in 0.56.0)* The `extra_files` key lists all files specified via the
+*(New in 0.56.0)* The `extra_files` key lists all files specified via
-`extra_files` kwarg of a build target. See [`executable()`](Reference-manual.md#executable).
+the `extra_files` kwarg of a build target. See
+[`executable()`](Reference-manual.md#executable).
 
-A target usually generates only one file. However, it is possible for custom
+A target usually generates only one file. However, it is possible for
-targets to have multiple outputs.
+custom targets to have multiple outputs.
 
 ### Target sources
 
-The `intro-targets.json` file also stores a list of all source objects of the
+The `intro-targets.json` file also stores a list of all source objects
-target in the `target_sources`. With this information, an IDE can provide code
+of the target in the `target_sources`. With this information, an IDE
-completion for all source files.
+can provide code completion for all source files.
 
 ```json
 {
@@ -94,11 +99,11 @@ completion for all source files.
 }
 ```
 
-It should be noted that the compiler parameters stored in the `parameters`
+It should be noted that the compiler parameters stored in the
-differ from the actual parameters used to compile the file. This is because
+`parameters` differ from the actual parameters used to compile the
-the parameters are optimized for the usage in an IDE to provide autocompletion
+file. This is because the parameters are optimized for the usage in an
-support, etc. It is thus not recommended to use this introspection information
+IDE to provide autocompletion support, etc. It is thus not recommended
-for actual compilation.
+to use this introspection information for actual compilation.
 
 ### Possible values for `type`
 
@@ -116,12 +121,13 @@ The following table shows all valid types for a target.
 
 ### Using `--targets` without a build directory
 
-It is also possible to get most targets without a build directory. This can be
+It is also possible to get most targets without a build directory.
-done by running `meson introspect --targets /path/to/meson.build`.
+This can be done by running `meson introspect --targets
+/path/to/meson.build`.
 
-The generated output is similar to running the introspection with a build
+The generated output is similar to running the introspection with a
-directory or reading the `intro-targets.json`. However, there are some key
+build directory or reading the `intro-targets.json`. However, there
-differences:
+are some key differences:
 
 - The paths in `filename` now are _relative_ to the future build directory
 - The `install_filename` key is completely missing
@@ -130,17 +136,18 @@ differences:
   - Empty lists for `compiler` and `parameters` and `generated_sources`
   - The `sources` list _should_ contain all sources of the target
 
-There is no guarantee that the sources list in `target_sources` is correct.
+There is no guarantee that the sources list in `target_sources` is
-There might be differences, due to internal limitations. It is also not
+correct. There might be differences, due to internal limitations. It
-guaranteed that all targets will be listed in the output. It might even be
+is also not guaranteed that all targets will be listed in the output.
-possible that targets are listed, which won't exist when meson is run normally.
+It might even be possible that targets are listed, which won't exist
-This can happen if a target is defined inside an if statement.
+when meson is run normally. This can happen if a target is defined
-Use this feature with care.
+inside an if statement. Use this feature with care.
 
 ## Build Options
 
-The list of all build options (build type, warning level, etc.) is stored in
+The list of all build options (build type, warning level, etc.) is
-the `intro-buildoptions.json` file. Here is the JSON format for each option.
+stored in the `intro-buildoptions.json` file. Here is the JSON format
+for each option.
 
 ```json
 {
@@ -161,8 +168,8 @@ The supported types are:
  - integer
  - array
 
-For the type `combo` the key `choices` is also present. Here all valid values
+For the type `combo` the key `choices` is also present. Here all valid
-for the option are stored.
+values for the option are stored.
 
 The possible values for `section` are:
 
@@ -174,8 +181,8 @@ The possible values for `section` are:
  - user
  - test
 
-The `machine` key specifies the machine configuration for the option. Possible
+The `machine` key specifies the machine configuration for the option.
-values are:
+Possible values are:
 
  - any
  - host
@@ -184,26 +191,28 @@ values are:
 To set the options, use the `meson configure` command.
 
 Since Meson 0.50.0 it is also possible to get the default buildoptions
-without a build directory by providing the root `meson.build` instead of a
+without a build directory by providing the root `meson.build` instead
-build directory to `meson introspect --buildoptions`.
+of a build directory to `meson introspect --buildoptions`.
 
-Running `--buildoptions` without a build directory produces the same output as
+Running `--buildoptions` without a build directory produces the same
-running it with a freshly configured build directory.
+output as running it with a freshly configured build directory.
 
-However, this behavior is not guaranteed if subprojects are present. Due to
+However, this behavior is not guaranteed if subprojects are present.
-internal limitations all subprojects are processed even if they are never used
+Due to internal limitations all subprojects are processed even if they
-in a real meson run. Because of this options for the subprojects can differ.
+are never used in a real meson run. Because of this options for the
+subprojects can differ.
 
 ## The dependencies section
 
 The list of all _found_ dependencies can be acquired from
-`intro-dependencies.json`. Here, the name, version, compiler and linker
+`intro-dependencies.json`. Here, the name, version, compiler and
-arguments for a dependency are listed.
+linker arguments for a dependency are listed.
 
 ### Scanning for dependecie with `--scan-dependencies`
 
-It is also possible to get most dependencies used without a build directory.
+It is also possible to get most dependencies used without a build
-This can be done by running `meson introspect --scan-dependencies /path/to/meson.build`.
+directory. This can be done by running `meson introspect
+--scan-dependencies /path/to/meson.build`.
 
 The output format is as follows:
 
@@ -219,28 +228,30 @@ The output format is as follows:
 ]
 ```
 
-The `required` keyword specifies whether the dependency is marked as required
+The `required` keyword specifies whether the dependency is marked as
-in the `meson.build` (all dependencies are required by default). The
+required in the `meson.build` (all dependencies are required by
-`conditional` key indicates whether the `dependency()` function was called
+default). The `conditional` key indicates whether the `dependency()`
-inside a conditional block. In a real meson run these dependencies might not be
+function was called inside a conditional block. In a real meson run
-used, thus they _may_ not be required, even if the `required` key is set. The
+these dependencies might not be used, thus they _may_ not be required,
-`has_fallback` key just indicates whether a fallback was directly set in the
+even if the `required` key is set. The `has_fallback` key just
-`dependency()` function. The `version` key always contains a list of version
+indicates whether a fallback was directly set in the `dependency()`
-requirements from the `meson.build` and **not** the actual version of the
+function. The `version` key always contains a list of version
-dependency on disc. The version list is empty if no version was specified
+requirements from the `meson.build` and **not** the actual version of
-in the `meson.build`.
+the dependency on disc. The version list is empty if no version was
+specified in the `meson.build`.
 
 ## Tests
 
-Compilation and unit tests are done as usual by running the `meson compile` and
+Compilation and unit tests are done as usual by running the `meson
-`meson test` commands. A JSON formatted result log can be found in
+compile` and `meson test` commands. A JSON formatted result log can be
-`workspace/project/builddir/meson-logs/testlog.json`.
+found in `workspace/project/builddir/meson-logs/testlog.json`.
 
-When these tests fail, the user probably wants to run the failing test in a
+When these tests fail, the user probably wants to run the failing test
-debugger. To make this as integrated as possible, extract the tests from the
+in a debugger. To make this as integrated as possible, extract the
-`intro-tests.json` and `intro-benchmarks.json` files. This provides you with
+tests from the `intro-tests.json` and `intro-benchmarks.json` files.
-all the information needed to run the test: what command to execute, command
+This provides you with all the information needed to run the test:
-line arguments, environment variable settings and how to process the output.
+what command to execute, command line arguments, environment variable
+settings and how to process the output.
 
 ```json
 {
@@ -260,14 +271,15 @@ line arguments, environment variable settings and how to process the output.
 ```
 
 The `depends` entry *(since 0.56.0)* contains target ids; they can be
-looked up in the targets introspection data.  The executable
+looked up in the targets introspection data. The executable pointed to
-pointed to by `cmd` is also included in the entry, as are any
+by `cmd` is also included in the entry, as are any arguments to the
-arguments to the test that are build products.
+test that are build products.
 
 ## Build system files
 
-It is also possible to get Meson build files used in your current project. This
+It is also possible to get Meson build files used in your current
-can be done by running `meson introspect --buildsystem-files /path/to/builddir`.
+project. This can be done by running `meson introspect
+--buildsystem-files /path/to/builddir`.
 
 The output format is as follows:
 
@@ -281,15 +293,18 @@ The output format is as follows:
 
 # Programmatic interface
 
-Meson also provides the `meson introspect` for project introspection via the
+Meson also provides the `meson introspect` for project introspection
-command line. Use `meson introspect -h` to see all available options.
+via the command line. Use `meson introspect -h` to see all available
+options.
 
-This API can also work without a build directory for the `--projectinfo` command.
+This API can also work without a build directory for the
+`--projectinfo` command.
 
 # AST of a `meson.build`
 
-Since meson *0.55.0* it is possible to dump the AST of a `meson.build` as a JSON
+Since meson *0.55.0* it is possible to dump the AST of a `meson.build`
-object. The interface for this is `meson introspect --ast /path/to/meson.build`.
+as a JSON object. The interface for this is `meson introspect --ast
+/path/to/meson.build`.
 
 Each node of the AST has at least the following entries:
 
@@ -332,9 +347,10 @@ Possible values for `node` with additional keys:
 | `UMinusNode`         | `right`: node                                    |
 | `TernaryNode`        | `condition`: node; `true`: node; `false`: node   |
 
-We do not guarantee the stability of this format since it is heavily linked to
+We do not guarantee the stability of this format since it is heavily
-the internal Meson AST. However, breaking changes (removal of a node type or the
+linked to the internal Meson AST. However, breaking changes (removal
-removal of a key) are unlikely and will be announced in the release notes.
+of a node type or the removal of a key) are unlikely and will be
+announced in the release notes.
 
 
 # Existing integrations

docs/markdown/Icestorm-module.md

@@ -2,14 +2,14 @@
 
 This module is available since version 0.45.0.
 
-**Note**: this module is unstable. It is only provided as a technology
+**Note**: this module is unstable. It is only provided as a technology
-preview.  Its API may change in arbitrary ways between releases or it
+preview. Its API may change in arbitrary ways between releases or it
 might be removed from Meson altogether.
 
 ## Usage
 
-This module provides an experimental method to create FPGA bitstreams using
+This module provides an experimental method to create FPGA bitstreams
-the [IceStorm](http://www.clifford.at/icestorm/) suite of tools.
+using the [IceStorm](http://www.clifford.at/icestorm/) suite of tools.
 
 The module exposes only one method called `project` and it is used
 like this:

docs/markdown/Include-directories.md

@@ -4,18 +4,27 @@ short-description: Instructions on handling include directories
 
 # Include directories
 
-Most `C`/`C++` projects have headers in different directories than sources. Thus you need to specify include directories. Let's assume that we are at some subdirectory and wish to add its `include` subdirectory to some target's search path. To create a include directory object we do this:
+Most `C`/`C++` projects have headers in different directories than
+sources. Thus you need to specify include directories. Let's assume
+that we are at some subdirectory and wish to add its `include`
+subdirectory to some target's search path. To create a include
+directory object we do this:
 
 ```meson
 incdir = include_directories('include')
 ```
 
-The `incdir` variable now holds a reference to the `include` subdir. Now we pass that as an argument to a build target:
+The `incdir` variable now holds a reference to the `include` subdir.
+Now we pass that as an argument to a build target:
 
 ```meson
 executable('someprog', 'someprog.c', include_directories : incdir)
 ```
 
-Note that these two commands can be given in any subdirectories and it will still work. Meson will keep track of the locations and generate proper compiler flags to make it all work.
+Note that these two commands can be given in any subdirectories and it
+will still work. Meson will keep track of the locations and generate
+proper compiler flags to make it all work.
 
-Another thing to note is that `include_directories` adds both the source directory and corresponding build directory to include path, so you don't have to care.
+Another thing to note is that `include_directories` adds both the
+source directory and corresponding build directory to include path, so
+you don't have to care.

docs/markdown/IndepthTutorial.md

@@ -1,8 +1,16 @@
 # An in-depth tutorial
 
-In this tutorial we set up a project with multiple targets, unit tests and dependencies between targets. Our main product is a shared library called *foo* that is written in `C++11`. We are going to ignore the contents of the source files, as they are not really important from a build definition point of view. The library makes use of the `GLib` library so we need to detect and link it properly. We also make the resulting library installable.
+In this tutorial we set up a project with multiple targets, unit tests
-
+and dependencies between targets. Our main product is a shared library
-The source tree contains three subdirectories `src`, `include` and `test` that contain, respectively, the source code, headers and unit tests of our project.
+called *foo* that is written in `C++11`. We are going to ignore the
+contents of the source files, as they are not really important from a
+build definition point of view. The library makes use of the `GLib`
+library so we need to detect and link it properly. We also make the
+resulting library installable.
+
+The source tree contains three subdirectories `src`, `include` and
+`test` that contain, respectively, the source code, headers and unit
+tests of our project.
 
 To start things up, here is the top level `meson.build` file.
 
@@ -27,23 +35,47 @@ pkg_mod.generate(libraries : foolib,
                  description : 'A Library to barnicate your foos.')
 ```
 
-The definition always starts with a call to the `project` function. In it you must specify the project's name and programming languages to use, in this case only `C++`. We also specify two additional arguments, the project's version and the license it is under. Our project is version `1.0.0` and is specified to be under the MIT license.
+The definition always starts with a call to the `project` function. In
-
+it you must specify the project's name and programming languages to
-Then we find GLib, which is an *external dependency*. The `dependency` function tells Meson to find the library (by default using `pkg-config`). If the library is not found, Meson will raise an error and stop processing the build definition.
+use, in this case only `C++`. We also specify two additional
-
+arguments, the project's version and the license it is under. Our
-Then we add a global compiler argument `-DSOME_TOKEN=value`. This flag is used for *all* C++ source file compilations. It is not possible to unset it for some targets. The reason for this is that it is hard to keep track of what compiler flags are in use if global settings change per target.
+project is version `1.0.0` and is specified to be under the MIT
-
+license.
-Since `include` directory contains the header files, we need a way to tell compilations to add that directory to the compiler command line. This is done with the `include_directories` command that takes a directory and returns an object representing this directory. It is stored in variable `inc` which makes it accessible later on.
+
-
+Then we find GLib, which is an *external dependency*. The `dependency`
-After this are three `subdir` commands. These instruct Meson to go to the specified subdirectory, open the `meson.build` file that's in there and execute it. The last few lines are a stanza to generate a `pkg-config` file. We'll skip that for now and come back to it at the end of this document.
+function tells Meson to find the library (by default using
-
+`pkg-config`). If the library is not found, Meson will raise an error
-The first subdirectory we go into is `include`. In it we have a a header file for the library that we want to install. This requires one line.
+and stop processing the build definition.
+
+Then we add a global compiler argument `-DSOME_TOKEN=value`. This flag
+is used for *all* C++ source file compilations. It is not possible to
+unset it for some targets. The reason for this is that it is hard to
+keep track of what compiler flags are in use if global settings change
+per target.
+
+Since `include` directory contains the header files, we need a way to
+tell compilations to add that directory to the compiler command line.
+This is done with the `include_directories` command that takes a
+directory and returns an object representing this directory. It is
+stored in variable `inc` which makes it accessible later on.
+
+After this are three `subdir` commands. These instruct Meson to go to
+the specified subdirectory, open the `meson.build` file that's in
+there and execute it. The last few lines are a stanza to generate a
+`pkg-config` file. We'll skip that for now and come back to it at the
+end of this document.
+
+The first subdirectory we go into is `include`. In it we have a a
+header file for the library that we want to install. This requires one
+line.
 
 ```meson
 install_headers('foolib.h')
 ```
 
-This installs the given header file to the system's header directory. This is by default `/[install prefix]/include`, but it can be changed with a command line argument.
+This installs the given header file to the system's header directory.
+This is by default `/[install prefix]/include`, but it can be changed
+with a command line argument.
 
 The Meson definition of `src` subdir is simple.
 
@@ -56,11 +88,22 @@ foolib = shared_library('foo',
                         install : true)
 ```
 
-Here we just tell Meson to build the library with the given sources. We also tell it to use the include directories we stored to variable `inc` earlier. Since this library uses GLib, we tell Meson to add all necessary compiler and linker flags with the `dependencies` keyword argument. Its value is `glib_dep` which we set at the top level `meson.build` file. The `install` argument tells Meson to install the result. As with the headers, the shared library is installed to the system's default location (usually `/[install prefix]/lib`) but is again overridable.
+Here we just tell Meson to build the library with the given sources.
+We also tell it to use the include directories we stored to variable
+`inc` earlier. Since this library uses GLib, we tell Meson to add all
+necessary compiler and linker flags with the `dependencies` keyword
+argument. Its value is `glib_dep` which we set at the top level
+`meson.build` file. The `install` argument tells Meson to install the
+result. As with the headers, the shared library is installed to the
+system's default location (usually `/[install prefix]/lib`) but is
+again overridable.
 
-The resulting library is stored in variable `foolib` just like the include directory was stored in the previous file.
+The resulting library is stored in variable `foolib` just like the
+include directory was stored in the previous file.
 
-Once Meson has processed the `src` subdir it returns to the main Meson file and executes the next line that moves it into the `test` subdir. Its contents look like this.
+Once Meson has processed the `src` subdir it returns to the main Meson
+file and executes the next line that moves it into the `test` subdir.
+Its contents look like this.
 
 ```meson
 testexe = executable('testexe', 'footest.cpp',
@@ -69,13 +112,30 @@ testexe = executable('testexe', 'footest.cpp',
 test('foolib test', testexe)
 ```
 
-First we build a test executable that has the same include directory as the main library and which also links against the freshly built shared library. Note that you don't need to specify `glib_dep` here just to be able to use the built library `foolib`. If the executable used GLib functionality itself, then we would of course need to add it as a keyword argument here.
+First we build a test executable that has the same include directory
-
+as the main library and which also links against the freshly built
-Finally we define a test with the name `foolib test`. It consists of running the binary we just built. If the executable exits with a zero return value, the test is considered passed. Nonzero return values mark the test as failed.
+shared library. Note that you don't need to specify `glib_dep` here
-
+just to be able to use the built library `foolib`. If the executable
-At this point we can return to the pkg-config generator line. All shared libraries should provide a pkg-config file, which explains how that library is used. Meson provides this simple generator that should be sufficient for most simple projects. All you need to do is list a few basic pieces of information and Meson takes care of generating an appropriate file. More advanced users might want to create their own pkg-config files using Meson's [configuration file generator system](Configuration.md).
+used GLib functionality itself, then we would of course need to add it
-
+as a keyword argument here.
-With these four files we are done. To configure, build and run the test suite, we just need to execute the following commands (starting at source tree root directory).
+
+Finally we define a test with the name `foolib test`. It consists of
+running the binary we just built. If the executable exits with a zero
+return value, the test is considered passed. Nonzero return values
+mark the test as failed.
+
+At this point we can return to the pkg-config generator line. All
+shared libraries should provide a pkg-config file, which explains how
+that library is used. Meson provides this simple generator that should
+be sufficient for most simple projects. All you need to do is list a
+few basic pieces of information and Meson takes care of generating an
+appropriate file. More advanced users might want to create their own
+pkg-config files using Meson's [configuration file generator
+system](Configuration.md).
+
+With these four files we are done. To configure, build and run the
+test suite, we just need to execute the following commands (starting
+at source tree root directory).
 
 ```console
 $ meson builddir && cd builddir

docs/markdown/Installing.md

@@ -4,7 +4,8 @@ short-description: Installing targets
 
 # Installing
 
-Invoked via the [following command](Commands.md#install) *(available since 0.47.0)*:
+Invoked via the [following command](Commands.md#install) *(available
+since 0.47.0)*:
 
 ```sh
 meson install
@@ -114,8 +115,8 @@ $ DESTDIR=/path/to/staging/area meson install
 
 ## Custom install behaviour
 
-Installation behaviour can be further customized using 
+Installation behaviour can be further customized using additional
-additional arguments.
+arguments.
 
 For example, if you wish to install the current setup without
 rebuilding the code (which the default install target always does) and

docs/markdown/Java.md

@@ -5,7 +5,8 @@ short-description: Compiling Java programs
 
 # Compiling Java applications
 
-Meson has experimental support for compiling Java programs. The basic syntax consists of only one function and would be used like this:
+Meson has experimental support for compiling Java programs. The basic
+syntax consists of only one function and would be used like this:
 
 ```meson
 project('javaprog', 'java')

docs/markdown/Keyval-module.md

@@ -8,13 +8,14 @@ authors:
 
 # keyval module
 
-This module parses files consisting of a series of `key=value` lines.  One use
+This module parses files consisting of a series of `key=value` lines.
-of this module is to load kconfig configurations in meson projects.
+One use of this module is to load kconfig configurations in meson
+projects.
 
-**Note**: this does not provide kconfig frontend tooling to generate a
+**Note**: this does not provide kconfig frontend tooling to generate a
 configuration. You still need something such as kconfig frontends (see
-link below) to parse your Kconfig files, and then (after you've
+link below) to parse your Kconfig files, and then (after you've chosen
-chosen the configuration options), output a ".config" file.
+the configuration options), output a ".config" file.
 
   [kconfig-frontends]: http://ymorin.is-a-geek.org/projects/kconfig-frontends
 
@@ -35,19 +36,21 @@ with the name `keyval`. You can, of course, replace the name
 This function loads a file consisting of a series of `key=value` lines
 and returns a dictionary object.
 
-`keyval.load()` makes no attempt at parsing the values in the file.
+`keyval.load()` makes no attempt at parsing the values in the file. In
-In particular boolean and integer values will be represented as strings,
+particular boolean and integer values will be represented as strings,
-and strings will keep any quoting that is present in the input file.  It
+and strings will keep any quoting that is present in the input file.
-can be useful to create a [`configuration_data()`](#configuration_data)
+It can be useful to create a
-object from the dictionary and use methods such as `get_unquoted()`.
+[`configuration_data()`](#configuration_data) object from the
+dictionary and use methods such as `get_unquoted()`.
 
 Kconfig frontends usually have ".config" as the default name for the
-configuration file.  However, placing the configuration file in the source
+configuration file. However, placing the configuration file in the
-directory limits the user to one configuration per source directory.
+source directory limits the user to one configuration per source
-In order to allow separate configurations for each build directory, as is
+directory. In order to allow separate configurations for each build
-the Meson standard, `meson.build` should not hardcode ".config" as the
+directory, as is the Meson standard, `meson.build` should not hardcode
-argument to `kconfig.load()`, and should instead make the argument to
+".config" as the argument to `kconfig.load()`, and should instead make
-`kconfig.load()` a [project build option](Build-options.md).
+the argument to `kconfig.load()` a [project build
+option](Build-options.md).
 
 * The first (and only) argument is the path to the configuration file to
   load (usually ".config").

docs/markdown/Localisation.md

@@ -4,9 +4,12 @@ short-description: Localization with GNU Gettext
 
 # Localisation
 
-Localising your application with GNU gettext takes a little effort but is quite straightforward. We'll create a `po` subdirectory at your project root directory for all the localisation info.
+Localising your application with GNU gettext takes a little effort but
+is quite straightforward. We'll create a `po` subdirectory at your
+project root directory for all the localisation info.
 
 ## Generating .pot and .po files
+
 In your main meson.build file include the `po` subdirectory in the build process.
 
     subdir('po')
@@ -17,12 +20,17 @@ In this `po` subdirectory we need:
 - `meson.build`: Localization specific meson file
 
 ### LINGUAS
+
 File with space separated list of languages. A sample LINGUAS might look like this.
 
     aa ab ae af
 
 ### POTFILES
-File that lists all the source files that gettext should scan in order to find strings to translate. The syntax of the file is one line per source file and the line must contain the relative path from source root. A sample POTFILES might look like this.
+
+File that lists all the source files that gettext should scan in order
+to find strings to translate. The syntax of the file is one line per
+source file and the line must contain the relative path from source
+root. A sample POTFILES might look like this.
 
     src/file1.c
     src/file2.c
@@ -30,7 +38,11 @@ File that lists all the source files that gettext should scan in order to find s
     include/mything/somefile.h
 
 ### meson.build
-Localization specific meson file. It imports and uses the `i18n` module. If not defined before it needs to define the `GETTEXT_PACKAGE` global.
+
+Localization specific meson file. It imports and uses the `i18n`
+module. If not defined before it needs to define the `GETTEXT_PACKAGE`
+global.
+
 ```meson
 i18n = import('i18n')
 # define GETTEXT_PACKAGE
@@ -39,13 +51,25 @@ i18n.gettext(meson.project_name(),
     args: '--directory=' + meson.source_root()
 )
 ```
-The first command imports the `i18n` module that provides gettext features. The fourth line does the actual invocation. The first argument is the gettext package name. This causes two things to happen. The first is that Meson will generate binary mo files and put them to their proper locations when doing an install. The second is that it creates a build rule to regenerate the main pot file. If you are using the Ninja backend, this is how you would invoke the rebuild.
+
+The first command imports the `i18n` module that provides gettext
+features. The fourth line does the actual invocation. The first
+argument is the gettext package name. This causes two things to
+happen. The first is that Meson will generate binary mo files and put
+them to their proper locations when doing an install. The second is
+that it creates a build rule to regenerate the main pot file. If you
+are using the Ninja backend, this is how you would invoke the rebuild.
 
 ### generate .pot file
 
-Then we need to generate the main pot file. The potfile can have any name but is usually the name of the gettext package. Let's say the project is called *intltest*. In this case the corresponding pot file would be called `intltest.pot`.
+Then we need to generate the main pot file. The potfile can have any
+name but is usually the name of the gettext package. Let's say the
+project is called *intltest*. In this case the corresponding pot file
+would be called `intltest.pot`.
 
-Run the following command from your build folder to generate the pot file. It is recommended to inspect it manually afterwards and fill in e.g. proper copyright and contact information.
+Run the following command from your build folder to generate the pot
+file. It is recommended to inspect it manually afterwards and fill in
+e.g. proper copyright and contact information.
 
 ```console
 $ meson compile intltest-pot
@@ -53,7 +77,9 @@ $ meson compile intltest-pot
 
 ### generate .po files
 
-For each language listed in the array above we need a corresponding `.po` file. Those can be generated by running the following command from your build folder.
+For each language listed in the array above we need a corresponding
+`.po` file. Those can be generated by running the following command
+from your build folder.
 
 ```console
 $ meson compile intltest-update-po

docs/markdown/Machine-files.md

@@ -1,12 +1,13 @@
 # Cross and Native File reference
 
-Cross and native files are nearly identical, but not completely. This is the
+Cross and native files are nearly identical, but not completely. This
-documentation on the common values used by both, for the specific values of
+is the documentation on the common values used by both, for the
-one or the other see the [cross compilation](Cross-compilation.md) and [native
+specific values of one or the other see the [cross
+compilation](Cross-compilation.md) and [native
 environments](Native-environments.md).
 
-*Changed in 0.56.0* Keys within sections are now case sensitive. This is
+*Changed in 0.56.0* Keys within sections are now case sensitive. This
-*required to make project options work correctly.
+*is required to make project options work correctly.
 
 ## Data Types
 
@@ -54,10 +55,10 @@ The following sections are allowed:
 
 *Since 0.56.0*
 
-String and list concatenation is supported using the `+` operator, joining paths
+String and list concatenation is supported using the `+` operator,
-is supported using the `/` operator.
+joining paths is supported using the `/` operator. Entries defined in
-Entries defined in the `[constants]` section can be used in any other section
+the `[constants]` section can be used in any other section (they are
-(they are always parsed first), entries in any other section can be used only
+always parsed first), entries in any other section can be used only
 within that same section and only after it has been defined.
 
 ```ini
@@ -73,8 +74,10 @@ cpp_args = c_args + ['-DSOMETHING_ELSE']
 c = toolchain / 'gcc'
 ```
 
-This can be useful with cross file composition as well. A generic cross file
+This can be useful with cross file composition as well. A generic
-could be composed with a platform specific file where constants are defined:
+cross file could be composed with a platform specific file where
+constants are defined:
+
 ```ini
 # aarch64.ini
 [constants]
@@ -91,10 +94,12 @@ pkgconfig = arch + '-pkg-config'
 ...
 ```
 
-This can be used as `meson setup --cross-file aarch64.ini --cross-file cross.ini builddir`.
+This can be used as `meson setup --cross-file aarch64.ini --cross-file
+cross.ini builddir`.
+
+Note that file composition happens before the parsing of values. The
+example below results in `b` being `'HelloWorld'`:
 
-Note that file composition happens before the parsing of values. The example
-below results in `b` being `'HelloWorld'`:
 ```ini
 # file1.ini:
 [constants]
@@ -108,8 +113,9 @@ b = a + 'World'
 a = 'Hello'
 ```
 
-The example below results in an error when file1.ini is included before file2.ini
+The example below results in an error when file1.ini is included
-because `b` would be defined before `a`:
+before file2.ini because `b` would be defined before `a`:
+
 ```ini
 # file1.ini:
 [constants]
@@ -130,15 +136,16 @@ internally by meson, or by the `find_program` function.
 These values must be either strings or an array of strings
 
 Compilers and linkers are defined here using `<lang>` and `<lang>_ld`.
-`<lang>_ld` is special because it is compiler specific. For compilers like
+`<lang>_ld` is special because it is compiler specific. For compilers
-gcc and clang which are used to invoke the linker this is a value to pass to
+like gcc and clang which are used to invoke the linker this is a value
-their "choose the linker" argument (-fuse-ld= in this case). For compilers
+to pass to their "choose the linker" argument (-fuse-ld= in this
-like MSVC and Clang-Cl, this is the path to a linker for meson to invoke,
+case). For compilers like MSVC and Clang-Cl, this is the path to a
-such as `link.exe` or `lld-link.exe`. Support for `ld` is *new in 0.53.0*
+linker for meson to invoke, such as `link.exe` or `lld-link.exe`.
+Support for `ld` is *new in 0.53.0*
 
-*changed in 0.53.1* the `ld` variable was replaced by `<lang>_ld`, because it
+*changed in 0.53.1* the `ld` variable was replaced by `<lang>_ld`,
-*regressed a large number of projects. in 0.53.0 the `ld` variable was used
+*because it regressed a large number of projects. in 0.53.0 the `ld`
-instead.
+*variable was used instead.
 
 Native example:
 
@@ -161,7 +168,9 @@ strip = '/usr/i586-mingw32msvc/bin/strip'
 pkgconfig = '/usr/bin/i586-mingw32msvc-pkg-config'
 ```
 
-An incomplete list of internally used programs that can be overridden here is:
+An incomplete list of internally used programs that can be overridden
+here is:
+
 - cmake
 - cups-config
 - gnustep-config
@@ -178,8 +187,9 @@ An incomplete list of internally used programs that can be overridden here is:
 
 *Deprecated in 0.56.0* use the built-in section instead.
 
-As of 0.50.0 paths and directories such as libdir can be defined in the native
+As of 0.50.0 paths and directories such as libdir can be defined in
-and cross files in a paths section. These should be strings.
+the native and cross files in a paths section. These should be
+strings.
 
 ```ini
 [paths]
@@ -187,10 +197,10 @@ libdir = 'mylibdir'
 prefix = '/my prefix'
 ```
 
-These values will only be loaded when not cross compiling. Any arguments on the
+These values will only be loaded when not cross compiling. Any
-command line will override any options in the native file. For example, passing
+arguments on the command line will override any options in the native
-`--libdir=otherlibdir` would result in a prefix of `/my prefix` and a libdir of
+file. For example, passing `--libdir=otherlibdir` would result in a
-`otherlibdir`.
+prefix of `/my prefix` and a libdir of `otherlibdir`.
 
 ### Properties
 
@@ -200,9 +210,9 @@ In addition to special data that may be specified in cross files, this
 section may contain random key value pairs accessed using the
 `meson.get_external_property()`, or `meson.get_cross_property()`.
 
-*Changed in 0.56.0* putting `<lang>_args` and `<lang>_link_args` in the
+*Changed in 0.56.0* putting `<lang>_args` and `<lang>_link_args` in
-properties section has been deprecated, and should be put in the built-in
+the properties section has been deprecated, and should be put in the
-options section.
+built-in options section.
 
 #### Supported properties
 
@@ -231,9 +241,10 @@ section.
 
 *New in 0.56.0*
 
-All variables set in the `[cmake]` section will be added to the generate CMake
+All variables set in the `[cmake]` section will be added to the
-toolchain file used for both CMake dependencies and CMake subprojects. The type
+generate CMake toolchain file used for both CMake dependencies and
-of each entry must be either a string or a list of strings.
+CMake subprojects. The type of each entry must be either a string or a
+list of strings.
 
 **Note:** All occurrences of `\` in the value of all keys will be replaced with
           a `/` since CMake has a lot of issues with correctly escaping `\` when
@@ -251,8 +262,8 @@ CMAKE_CXX_COMPILER  = 'C:\\user\\bin\\g++'
 CMAKE_SOME_VARIABLE = ['some', 'value with spaces']
 ```
 
-For instance, the `[cmake]` section from above will generate the following
+For instance, the `[cmake]` section from above will generate the
-code in the CMake toolchain file:
+following code in the CMake toolchain file:
 
 ```cmake
 set(CMAKE_C_COMPILER    "/usr/bin/gcc")
@@ -264,14 +275,16 @@ set(CMAKE_SOME_VARIABLE "some" "value with spaces")
 
 *New in 0.56.0*
 
-Path options are not allowed, those must be set in the `[paths]` section.
+Path options are not allowed, those must be set in the `[paths]`
+section.
 
-Being able to set project specific options in a cross or native file can be
+Being able to set project specific options in a cross or native file
-done using the `[project options]` section of the specific file (if doing a
+can be done using the `[project options]` section of the specific file
-cross build the options from the native file will be ignored)
+(if doing a cross build the options from the native file will be
+ignored)
 
-For setting options in subprojects use the `[<subproject>:project options]`
+For setting options in subprojects use the `[<subproject>:project
-section instead.
+options]` section instead.
 
 ```ini
 [project options]
@@ -290,8 +303,9 @@ Meson built-in options can be set the same way:
 c_std = 'c99'
 ```
 
-You can set some meson built-in options on a per-subproject basis, such as
+You can set some meson built-in options on a per-subproject basis,
-`default_library` and `werror`. The order of precedence is:
+such as `default_library` and `werror`. The order of precedence is:
+
 1) Command line
 2) Machine file
 3) Build system definitions
@@ -302,9 +316,9 @@ default_library = 'static'
 werror = false
 ```
 
-Options set on a per-subproject basis will inherit the
+Options set on a per-subproject basis will inherit the option from the
-option from the parent if the parent has a setting but the subproject
+parent if the parent has a setting but the subproject doesn't, even
-doesn't, even when there is a default set meson language.
+when there is a default set meson language.
 
 ```ini
 [built-in options]
@@ -313,9 +327,10 @@ default_library = 'static'
 
 will make subprojects use default_library as static.
 
-Some options can be set on a per-machine basis (in other words, the value of
+Some options can be set on a per-machine basis (in other words, the
-the build machine can be different than the host machine in a cross compile).
+value of the build machine can be different than the host machine in a
-In these cases the values from both a cross file and a native file are used.
+cross compile). In these cases the values from both a cross file and a
+native file are used.
 
 An incomplete list of options is:
 - pkg_config_path
@@ -323,21 +338,21 @@ An incomplete list of options is:
 
 ## Loading multiple machine files
 
-Native files allow layering (cross files can be layered since meson 0.52.0).
+Native files allow layering (cross files can be layered since meson
-More than one file can be loaded, with values from a previous file being
+0.52.0). More than one file can be loaded, with values from a previous
-overridden by the next. The intention of this is not overriding, but to allow
+file being overridden by the next. The intention of this is not
-composing files. This composition is done by passing the command line
+overriding, but to allow composing files. This composition is done by
-argument multiple times:
+passing the command line argument multiple times:
 
 ```console
 meson setup builddir/ --cross-file first.ini --cross-file second.ini --cross-file thrid.ini
 ```
 
-In this case `first.ini` will be loaded, then `second.ini`, with values from
+In this case `first.ini` will be loaded, then `second.ini`, with
-`second.ini` replacing `first.ini`, and so on.
+values from `second.ini` replacing `first.ini`, and so on.
 
-For example, if there is a project using C and C++, python 3.4-3.7, and LLVM
+For example, if there is a project using C and C++, python 3.4-3.7,
-5-7, and it needs to build with clang 5, 6, and 7, and gcc 5.x, 6.x, and 7.x;
+and LLVM 5-7, and it needs to build with clang 5, 6, and 7, and gcc
-expressing all of these configurations in monolithic configurations would
+5.x, 6.x, and 7.x; expressing all of these configurations in
-result in 81 different native files. By layering them, it can be expressed by
+monolithic configurations would result in 81 different native files.
-just 12 native files.
+By layering them, it can be expressed by just 12 native files.

docs/markdown/Meson-sample.md

@@ -11,11 +11,18 @@ project('simple', 'c')
 executable('myexe', 'source.c')
 ```
 
-All Meson build definitions begin with the `project` command. It specifies the name of the project and what programming languages it uses. Here the project is called *simple* and it uses only the C programming language. All strings are single-quoted.
+All Meson build definitions begin with the `project` command. It
+specifies the name of the project and what programming languages it
+uses. Here the project is called *simple* and it uses only the C
+programming language. All strings are single-quoted.
 
-On the next line we define a *build target*, in this case an executable called *myexe*. It consists of one source file. This is all the code that a user needs to write to compile an executable with Meson.
+On the next line we define a *build target*, in this case an
+executable called *myexe*. It consists of one source file. This is all
+the code that a user needs to write to compile an executable with
+Meson.
 
-Variables are fully supported. The above code snippet could also have been declared like this.
+Variables are fully supported. The above code snippet could also have
+been declared like this.
 
 ```meson
 project('simple', 'c')
@@ -23,7 +30,8 @@ src = 'source.c'
 executable('myexe', src)
 ```
 
-Most executables consist of more than one source file. The easiest way to deal with this is to put them in an array.
+Most executables consist of more than one source file. The easiest way
+to deal with this is to put them in an array.
 
 ```meson
 project('simple', 'c')
@@ -31,7 +39,9 @@ src = ['source1.c', 'source2.c', 'source3.c']
 executable('myexe', src)
 ```
 
-Meson also supports the notion of *keyword arguments*. Indeed most arguments to functions can only be passed using them. The above snippet could be rewritten like this.
+Meson also supports the notion of *keyword arguments*. Indeed most
+arguments to functions can only be passed using them. The above
+snippet could be rewritten like this.
 
 ```meson
 project('simple', 'c')
@@ -39,9 +49,12 @@ src = ['source1.c', 'source2.c', 'source3.c']
 executable('myexe', sources : src)
 ```
 
-These two formats are equivalent and choosing one over the other is mostly a question of personal preference.
+These two formats are equivalent and choosing one over the other is
+mostly a question of personal preference.
 
-The `executable` command actually returns an *executable object*, which represents the given build target. It can be passed on to other functions, like this.
+The `executable` command actually returns an *executable object*,
+which represents the given build target. It can be passed on to other
+functions, like this.
 
 ```meson
 project('simple', 'c')
@@ -50,9 +63,18 @@ exe = executable('myexe', src)
 test('simple test', exe)
 ```
 
-Here we create a unit test called *simple test*, and which uses the built executable. When the tests are run with the `meson test` command, the built executable is run. If it returns zero, the test passes. A non-zero return value indicates an error, which Meson will then report to the user.
+Here we create a unit test called *simple test*, and which uses the
+built executable. When the tests are run with the `meson test`
+command, the built executable is run. If it returns zero, the test
+passes. A non-zero return value indicates an error, which Meson will
+then report to the user.
 
 A note to Visual Studio users
 -----
 
-There's a slight terminology difference between Meson and Visual Studio. A Meson *project* is the equivalent to a Visual Studio *solution*. That is, the topmost thing that encompasses all things to be built. A Visual Studio *project* on the other hand is the equivalent of a Meson top level build target, such as an executable or a shared library.
+There's a slight terminology difference between Meson and Visual
+Studio. A Meson *project* is the equivalent to a Visual Studio
+*solution*. That is, the topmost thing that encompasses all things to
+be built. A Visual Studio *project* on the other hand is the
+equivalent of a Meson top level build target, such as an executable or
+a shared library.

docs/markdown/MesonCI.md

@@ -1,46 +1,43 @@
 # Meson CI setup
 
-This document is aimed for Meson contributors and documents
+This document is aimed for Meson contributors and documents the CI
-the CI setup used for testing Meson itself. The Meson
+setup used for testing Meson itself. The Meson project uses multiple
-project uses multiple CI platforms for covering a wide
+CI platforms for covering a wide range of target systems.
-range of target systems.
 
 ## GitHub actions
 
 The configuration files for GitHub actions are located in
-`.github/workflows`. Here, all [images](#docker-images)
+`.github/workflows`. Here, all [images](#docker-images) are tested
-are tested  with the full `run_tests.py` run. Additionally,
+with the full `run_tests.py` run. Additionally, some other, smaller,
-some other, smaller, tests are run.
+tests are run.
 
 ## Docker images
 
-The Linux docker images are automatically built and
+The Linux docker images are automatically built and uploaded by GitHub
-uploaded by GitHub actions. An image rebuild is triggerd
+actions. An image rebuild is triggerd when any of the image definition
-when any of the image definition files are changed (in
+files are changed (in `ci/ciimage`) in the master branch.
-`ci/ciimage`) in the master branch. Additionally, the
+Additionally, the images are also updated weekly.
-images are also updated weekly.
 
-Each docker image has one corresponding dirctory in
+Each docker image has one corresponding dirctory in `ci/ciimage` with
-`ci/ciimage` with an `image.json` and an `install.sh`.
+an `image.json` and an `install.sh`.
 
 ### Image generation
 
 There are no manual Dockerfiles. Instead the Dockerfile is
-automatically generated by the `build.py` script. This is
+automatically generated by the `build.py` script. This is done to
-done to ensure that all images have the same layout and can
+ensure that all images have the same layout and can all be built and
-all be built and tested automatically.
+tested automatically.
 
-The Dockerfile is generated from the `image.json` file and
+The Dockerfile is generated from the `image.json` file and basically
-basically only adds a few common files and runs the
+only adds a few common files and runs the `install.sh` script which
-`install.sh` script which should contain all distribution
+should contain all distribution specific setup steps. The `common.sh`
-specific setup steps. The `common.sh` can be sourced via
+can be sourced via `source /ci/common.sh` to access some shared
-`source /ci/common.sh` to access some shared functionalety.
+functionalety.
 
-To generate the image run `build.py -t build <image>`. A
+To generate the image run `build.py -t build <image>`. A generated
-generated image can be tested with `build.py -t test <image>`.
+image can be tested with `build.py -t test <image>`.
 
 ### Common image setup
 
-Each docker image has a `/ci` directory with an
+Each docker image has a `/ci` directory with an `env_vars.sh` script.
-`env_vars.sh` script. This script has to be sourced before
+This script has to be sourced before running the meson test suite.
-running the meson test suite.

docs/markdown/Mixing-build-systems.md

@@ -2,21 +2,21 @@
 
 Meson has been designed with the principle that all dependencies are
 either provided by "the platform" via a mechanism such as Pkg-Config
-or that they are built as Meson subprojects under the main
+or that they are built as Meson subprojects under the main project.
-project. There are several projects that would like to mix build
+There are several projects that would like to mix build systems, that
-systems, that is, build dependencies in the same build directory as
+is, build dependencies in the same build directory as the other build
-the other build system by having one build system call the other. The
+system by having one build system call the other. The build
-build directories do not necessarily need to be inside each other, but
+directories do not necessarily need to be inside each other, but that
-that is the common case.
+is the common case.
-
+
-This page lists the Meson project's stance on mixing build
+This page lists the Meson project's stance on mixing build systems.
-systems. The tl/dr version is that while we do provide some
+The tl/dr version is that while we do provide some functionality for
-functionality for this use case, it only works for simple
+this use case, it only works for simple cases. Anything more complex
-cases. Anything more complex can not be made reliable and trying to do
+can not be made reliable and trying to do that would burden Meson
-that would burden Meson developers with an effectively infinite
+developers with an effectively infinite maintenance burden. Thus these
-maintenance burden. Thus these use cases are not guaranteed to work,
+use cases are not guaranteed to work, and even if a project using them
-and even if a project using them works today there are no guarantees
+works today there are no guarantees that it will work in any future
-that it will work in any future version.
+version.
 
 ## The definition of "build system mixing"
 

docs/markdown/Modules.md

@@ -4,13 +4,16 @@ short-description: Meson modules for common build operations
 
 # Modules
 
-In addition to core language features, Meson also provides a module system aimed at providing helper methods for common build operations. Using modules is simple, first you import them:
+In addition to core language features, Meson also provides a module
+system aimed at providing helper methods for common build operations.
+Using modules is simple, first you import them:
 
 ```meson
 mymod = import('somemodule')
 ```
 
-After this you can use the returned object to use the functionality provided:
+After this you can use the returned object to use the functionality
+provided:
 
 ```meson
 mymod.do_something('text argument')

docs/markdown/Native-environments.md

@@ -6,15 +6,16 @@ short-description: Setting up native compilation
 
 New in 0.49.0
 
-Meson has [cross files for describing cross compilation environments](Cross-compilation.md),
+Meson has [cross files for describing cross compilation
-for describing native environments it has equivalent "native files".
+environments](Cross-compilation.md), for describing native
+environments it has equivalent "native files".
 
-Natives describe the *build machine*, and can be used to override properties of
+Natives describe the *build machine*, and can be used to override
-non-cross builds, as well as properties that are marked as "native" in a cross
+properties of non-cross builds, as well as properties that are marked
-build.
+as "native" in a cross build.
 
-There are a couple of reasons you might want to use a native file to keep a
+There are a couple of reasons you might want to use a native file to
-persistent environment:
+keep a persistent environment:
 
 * To build with a non-default native tool chain (such as clang instead of gcc)
 * To use a non-default version of another binary, such as yacc, or llvm-config
@@ -44,6 +45,6 @@ The order of locations tried is as follows:
  - The user local location
  - The system wide locations in order
 
-These files are not intended to be shipped by distributions, unless they are
+These files are not intended to be shipped by distributions, unless
-specifically for distribution packaging, they are mainly intended for
+they are specifically for distribution packaging, they are mainly
-developers.
+intended for developers.

docs/markdown/Performance-comparison.md

@@ -1,6 +1,7 @@
 # Performance comparison
 
-This page lists experiments comparing build performance between Meson and other build systems.
+This page lists experiments comparing build performance between Meson
+and other build systems.
 
 - [Simple comparison](Simple-comparison.md)
 - [ARM performance test](ARM-performance-test.md)

docs/markdown/Pkg-config-files.md

@@ -1,6 +1,13 @@
 # Pkg config files
 
-[Pkg-config](https://en.wikipedia.org/wiki/Pkg-config) is a way for shared libraries to declare the compiler flags needed to use them. There are two different ways of generating Pkg-config files in Meson. The first way is to build them manually with the `configure_file` command. The second way is to use Meson's built in Pkg-config file generator. The difference between the two is that the latter is very simple and meant for basic use cases. The former should be used when you need to provide a more customized solution.
+[Pkg-config](https://en.wikipedia.org/wiki/Pkg-config) is a way for
+shared libraries to declare the compiler flags needed to use them.
+There are two different ways of generating Pkg-config files in Meson.
+The first way is to build them manually with the `configure_file`
+command. The second way is to use Meson's built in Pkg-config file
+generator. The difference between the two is that the latter is very
+simple and meant for basic use cases. The former should be used when
+you need to provide a more customized solution.
 
 In this document we describe the simple generator approach. It is used in the following way.
 
@@ -16,6 +23,8 @@ pkg.generate(libraries : libs,
              description : 'A simple demo library.')
 ```
 
-This causes a file called `simple.pc` to be created and placed into the install directory during the install phase.
+This causes a file called `simple.pc` to be created and placed into
+the install directory during the install phase.
 
-More information on the pkg-config module and the parameters can be found on the [pkgconfig-module](Pkgconfig-module.md) page.
+More information on the pkg-config module and the parameters can be
+found on the [pkgconfig-module](Pkgconfig-module.md) page.

docs/markdown/Pkgconfig-module.md

@@ -62,27 +62,29 @@ keyword arguments.
    pkg-config files in projects which also have architecture-dependent outputs.
 - `conflicts` (*since 0.36.0, incorrectly issued a warning prior to 0.54.0*) list of strings to be put in the `Conflicts` field.
 
-Since 0.46 a `StaticLibrary` or `SharedLibrary` object can optionally be passed
+Since 0.46 a `StaticLibrary` or `SharedLibrary` object can optionally
-as first positional argument. If one is provided a default value will be
+be passed as first positional argument. If one is provided a default
-provided for all required fields of the pc file:
+value will be provided for all required fields of the pc file:
 - `install_dir` is set to `pkgconfig` folder in the same location than the provided library.
 - `description` is set to the project's name followed by the library's name.
 - `name` is set to the library's name.
 
-Since 0.54.0 uninstalled pkg-config files are generated as well. They are
+Since 0.54.0 uninstalled pkg-config files are generated as well. They
-located in `<build dir>/meson-uninstalled/`. It is sometimes
+are located in `<build dir>/meson-uninstalled/`. It is sometimes
-useful to build projects against libraries built by meson without having to
+useful to build projects against libraries built by meson without
-install them into a prefix. In order to do so, just set
+having to install them into a prefix. In order to do so, just set
 `PKG_CONFIG_PATH=<builddir>/meson-uninstalled` before building your
-application. That will cause pkg-config to prefer those `-uninstalled.pc` files
+application. That will cause pkg-config to prefer those
-and find libraries and headers from the meson builddir. This is an experimental
+`-uninstalled.pc` files and find libraries and headers from the meson
-feature provided on a best-effort basis, it might not work in all use-cases.
+builddir. This is an experimental feature provided on a best-effort
+basis, it might not work in all use-cases.
 
 ### Implicit dependencies
 
-The exact rules followed to find dependencies that are implicitly added into the
+The exact rules followed to find dependencies that are implicitly
-pkg-config file have evolved over time. Here are the rules as of Meson *0.49.0*,
+added into the pkg-config file have evolved over time. Here are the
-previous versions might have slightly different behaviour.
+rules as of Meson *0.49.0*, previous versions might have slightly
+different behaviour.
 
 - Not found libraries or dependencies are ignored.
 - Libraries and dependencies are private by default (i.e. added into

docs/markdown/Playground.md

@@ -1,10 +1,14 @@
 # playground
 
-This page is *not* part of official documentation. It exists merely for testing new stuff for the wiki.
+This page is *not* part of official documentation. It exists merely
+for testing new stuff for the wiki.
 
 ## Ref manual reformat
 
-The current format is not very readable. We should have something more like what [glib](https://developer.gnome.org/glib/stable/glib-Hash-Tables.html) or [Python](https://docs.python.org/3/library/os.html) do.
+The current format is not very readable. We should have something more
+like what
+[glib](https://developer.gnome.org/glib/stable/glib-Hash-Tables.html)
+or [Python](https://docs.python.org/3/library/os.html) do.
 
 Here's a first proposal.
 

docs/markdown/Porting-from-autotools.md

@@ -1,12 +1,18 @@
 # Porting from Autotools
 
-This page uses [AppStream-glib](https://github.com/hughsie/appstream-glib/) as an example project. AppStream-Glib contains some libraries, GObject Introspection data, tests, man pages, i18n, bash-completion with optional flags to build/not build support for some things.
+This page uses
+[AppStream-glib](https://github.com/hughsie/appstream-glib/) as an
+example project. AppStream-Glib contains some libraries, GObject
+Introspection data, tests, man pages, i18n, bash-completion with
+optional flags to build/not build support for some things.
 
-Meson comes with a helper script `ac_converter` that you can use to convert the basic autoconf checks for your project.
+Meson comes with a helper script `ac_converter` that you can use to
+convert the basic autoconf checks for your project.
 
 ## Configure.ac
 
-First let's look at `configure.ac` and write the same in `meson.build`.
+First let's look at `configure.ac` and write the same in
+`meson.build`.
 
 ```autoconf
 AC_PREREQ(2.63)
@@ -54,7 +60,8 @@ AC_SUBST(AS_MICRO_VERSION)
 AC_SUBST(AS_VERSION)
 ```
 
-You don't need to do the same in Meson, because it does not have two different types of files (Makefile, configure).
+You don't need to do the same in Meson, because it does not have two
+different types of files (Makefile, configure).
 
 ### Auto headers
 
@@ -74,9 +81,12 @@ configure_file(output : 'config.h',
                configuration : conf)
 ```
 
-Meson doesn't support autoheaders, you need to manually specify what do you want to see in header file, write `configuration_data()` object and use `configure_file()`.
+Meson doesn't support autoheaders, you need to manually specify what
+do you want to see in header file, write `configuration_data()` object
+and use `configure_file()`.
 
-You can also substitute variables of type `@SOME_VAR@` with configure data. The details are on the [configuration page](Configuration.md).
+You can also substitute variables of type `@SOME_VAR@` with configure
+data. The details are on the [configuration page](Configuration.md).
 
 ### Finding programs
 
@@ -148,7 +158,8 @@ option('enable-dep11', type : 'boolean', value : true, description : 'enable DEP
 
 ## Makefile.am
 
-Next step is `Makefile.am`. In meson you don't need to have other file, you still use `meson.build`.
+Next step is `Makefile.am`. In meson you don't need to have other
+file, you still use `meson.build`.
 
 ### Sub directories
 
@@ -193,7 +204,10 @@ EXTRA_DIST =                                            \
         config.h
 ```
 
-In Meson you don't need have `*CLEANFILES`, because in meson you are building in temporary directory (usually called `build`), you manually removing it. You also not need to use `EXTRA_DIST`, because you will make tarballs via `git archive` or something like this.
+In Meson you don't need have `*CLEANFILES`, because in meson you are
+building in temporary directory (usually called `build`), you manually
+removing it. You also not need to use `EXTRA_DIST`, because you will
+make tarballs via `git archive` or something like this.
 
 ### glib-compile-resources
 

docs/markdown/Precompiled-headers.md

@@ -40,9 +40,9 @@ Toggling the usage of precompiled headers
 
 If you wish to compile your project without precompiled headers, you
 can change the value of the pch option by passing `-Db_pch=false`
-argument to Meson at configure time or later with `meson configure`. You can
+argument to Meson at configure time or later with `meson configure`.
-also toggle the use of pch in a configured build directory with the
+You can also toggle the use of pch in a configured build directory
-GUI tool. You don't have to do any changes to the source
+with the GUI tool. You don't have to do any changes to the source
 code. Typically this is done to test whether your project compiles
 cleanly without pch (that is, checking that its #includes are in
 order) and working around compiler bugs.
@@ -51,11 +51,11 @@ Using precompiled headers with GCC and derivatives
 --
 
 Once you have a file to precompile, you can enable the use of pch for
-a given target with a *pch* keyword argument. As an example, let's assume
+a given target with a *pch* keyword argument. As an example, let's
-you want to build a small C binary with precompiled headers.
+assume you want to build a small C binary with precompiled headers.
-Let's say the source files of the binary use the system headers `stdio.h`
+Let's say the source files of the binary use the system headers
-and `string.h`. Then you create a header file `pch/myexe_pch.h` with this
+`stdio.h` and `string.h`. Then you create a header file
-content:
+`pch/myexe_pch.h` with this content:
 
 ```c
 #include <stdio.h>

docs/markdown/Python-3-module.md

@@ -3,18 +3,21 @@
 This module provides support for dealing with Python 3. It has the
 following methods.
 
-This module is deprecated and replaced by the [python](Python-module.md) module.
+This module is deprecated and replaced by the
+[python](Python-module.md) module.
 
 ## find_python
 
 This is a cross platform way of finding the Python 3 executable, which
 may have a different name on different operating systems. Returns an
-[external program](Reference-manual.md#external-program-object) object.
+[external program](Reference-manual.md#external-program-object)
+object.
 
 *Added 0.38.0*
 
-Deprecated, replaced by [`find_installation`](Python-module.md#find_installation)
+Deprecated, replaced by
-function from `python` module.
+[`find_installation`](Python-module.md#find_installation) function
+from `python` module.
 
 ## extension_module
 
@@ -29,8 +32,9 @@ need to add `dependencies : dependency('python3')`, see
 
 *Added 0.38.0*
 
-Deprecated, replaced by [`extension_module`](Python-module.md#extension_module)
+Deprecated, replaced by
-method from `python` module.
+[`extension_module`](Python-module.md#extension_module) method from
+`python` module.
 
 ## language_version
 
@@ -38,8 +42,9 @@ Returns a string with the Python language version such as `3.5`.
 
 *Added 0.40.0*
 
-Deprecated, replaced by [`language_version`](Python-module.md#language_version)
+Deprecated, replaced by
-method from `python` module.
+[`language_version`](Python-module.md#language_version) method from
+`python` module.
 
 ## sysconfig_path
 

docs/markdown/Python-module.md

@@ -34,10 +34,10 @@ If provided, it can be:
 
 - A path, eg `/usr/local/bin/python3.4m`
 
-- One of `python2` or `python3`: in either case, the module will try some
+- One of `python2` or `python3`: in either case, the module will try
-  alternative names: `py -2` or `py -3` on Windows, and `python` everywhere.
+  some alternative names: `py -2` or `py -3` on Windows, and `python`
-  In the latter case, it will check whether the version provided by the
+  everywhere. In the latter case, it will check whether the version
-  sysconfig module matches the required major version
+  provided by the sysconfig module matches the required major version
 
 Keyword arguments are the following:
 
@@ -83,8 +83,9 @@ shared_module py_installation.extension_module(module_name, list_of_sources, ...
 Create a `shared_module` target that is named according to the naming
 conventions of the target platform.
 
-All positional and keyword arguments are the same as for [shared_module],
+All positional and keyword arguments are the same as for
-excluding `name_suffix` and `name_prefix`, and with the addition of the following:
+[shared_module], excluding `name_suffix` and `name_prefix`, and with
+the addition of the following:
 
 - `subdir`: By default, meson will install the extension module in
   the relevant top-level location for the python installation, eg
@@ -92,8 +93,9 @@ excluding `name_suffix` and `name_prefix`, and with the addition of the followin
   it will be appended to that location. This keyword argument is
   mutually exclusive with `install_dir`
 
-`extension_module` does not add any dependencies to the library so user may
+`extension_module` does not add any dependencies to the library so
-need to add `dependencies : py_installation.dependency()`, see [][`dependency()`].
+user may need to add `dependencies : py_installation.dependency()`,
+see [][`dependency()`].
 
 **Returns**: a [buildtarget object]
 
@@ -103,12 +105,13 @@ need to add `dependencies : py_installation.dependency()`, see [][`dependency()`
 python_dependency py_installation.dependency(...)
 ```
 
-This method accepts no positional arguments, and the same keyword arguments as
+This method accepts no positional arguments, and the same keyword
-the standard [dependency] function. It also supports the following keyword
+arguments as the standard [dependency] function. It also supports the
-argument:
+following keyword argument:
 
-- `embed`: *(since 0.53.0)* If true, meson will try to find a python dependency
+- `embed`: *(since 0.53.0)* If true, meson will try to find a python
-  that can be used for embedding python into an application.
+  dependency that can be used for embedding python into an
+  application.
 
 **Returns**: a [python dependency][`python_dependency` object]
 
@@ -120,14 +123,14 @@ void py_installation.install_sources(list_of_files, ...)
 
 Install actual python sources (`.py`).
 
-All positional and keyword arguments are the same as for [install_data],
+All positional and keyword arguments are the same as for
-with the addition of the following:
+[install_data], with the addition of the following:
 
-- `pure`: On some platforms, architecture independent files are expected
+- `pure`: On some platforms, architecture independent files are
-  to be placed in a separate directory. However, if the python sources
+  expected to be placed in a separate directory. However, if the
-  should be installed alongside an extension module built with this
+  python sources should be installed alongside an extension module
-  module, this keyword argument can be used to override that behaviour.
+  built with this module, this keyword argument can be used to
-  Defaults to `true`
+  override that behaviour. Defaults to `true`
 
 - `subdir`: See documentation for the argument of the same name to
   [][`extension_module()`]
@@ -140,8 +143,8 @@ string py_installation.get_install_dir(...)
 
 Retrieve the directory [][`install_sources()`] will install to.
 
-It can be useful in cases where `install_sources` cannot be used directly,
+It can be useful in cases where `install_sources` cannot be used
-for example when using [configure_file].
+directly, for example when using [configure_file].
 
 This function accepts no arguments, its keyword arguments are the same
 as [][`install_sources()`].
@@ -223,14 +226,15 @@ a non-existing variable will cause a fatal error.
     bool py_installation.has_variable(variable_name)
 ```
 
-**Returns**: true if a variable named `variable_name` can be retrieved with
+**Returns**: true if a variable named `variable_name` can be retrieved
-[][`get_variable()`], false otherwise.
+with [][`get_variable()`], false otherwise.
 
 ## `python_dependency` object
 
-This [dependency object] subclass will try various methods to obtain the
+This [dependency object] subclass will try various methods to obtain
-compiler and linker arguments, starting with pkg-config then potentially
+the compiler and linker arguments, starting with pkg-config then
-using information obtained from python's `sysconfig` module.
+potentially using information obtained from python's `sysconfig`
+module.
 
 It exposes the same methods as its parent class.
 

docs/markdown/Qt5-module.md

@@ -25,14 +25,15 @@ This method generates the necessary targets to build translation files with lrel
  - `qresource` rcc source file to extract ts_files from; cannot be used with ts_files kwarg. Available since v0.56.0.
  - `rcc_extra_arguments`, any additional arguments to `rcc` (optional), when used with `qresource. Available since v0.56.0.
 
-Returns either: a list of custom targets for the compiled translations, or, if
+Returns either: a list of custom targets for the compiled
-using a `qresource` file, a single custom target containing the processed
+translations, or, if using a `qresource` file, a single custom target
-source file, which should be passed to a main build target.
+containing the processed source file, which should be passed to a main
+build target.
 
 ## has_tools
 
-This method returns `true` if all tools used by this module are found, `false`
+This method returns `true` if all tools used by this module are found,
-otherwise.
+`false` otherwise.
 
 It should be used to compile optional Qt code:
 ```meson
@@ -56,10 +57,11 @@ This method takes the following keyword arguments:
 See [Qt dependencies](Dependencies.md#qt4-qt5)
 
 The 'modules' argument is used to include Qt modules in the project.
-See the Qt documentation for the [list of modules](http://doc.qt.io/qt-5/qtmodules.html).
+See the Qt documentation for the [list of
+modules](http://doc.qt.io/qt-5/qtmodules.html).
 
-The 'private_headers' argument allows usage of Qt's modules private headers.
+The 'private_headers' argument allows usage of Qt's modules private
-(since v0.47.0)
+headers. (since v0.47.0)
 
 ## Example
 A simple example would look like this:
@@ -78,9 +80,10 @@ executable('myprog', 'main.cpp', 'myclass.cpp', moc_files,
            dependencies : qt5_dep)
 ```
 
-Sometimes, translations are embedded inside the binary using qresource files.
+Sometimes, translations are embedded inside the binary using qresource
-In this case the ts files do not need to be explicitly listed, but will be
+files. In this case the ts files do not need to be explicitly listed,
-inferred from the built qm files listed in the qresource file. For example:
+but will be inferred from the built qm files listed in the qresource
+file. For example:
 
 ```meson
 qt5 = import('qt5')

docs/markdown/Quick-guide.md

@@ -9,8 +9,9 @@ Meson has been designed to be as simple to use as possible. This page
 outlines the initial steps needed for installation, troubleshooting,
 and standard use.
 
-For more advanced configuration please refer to the command line help `meson --help`
+For more advanced configuration please refer to the command line help
-or the Meson documentation located at the [Mesonbuild](https://mesonbuild.com) website.
+`meson --help` or the Meson documentation located at the
+[Mesonbuild](https://mesonbuild.com) website.
 
 Table of Contents:
 * [Requirements](#requirements)
@@ -57,7 +58,8 @@ Install as root:
 $ pip3 install meson
 ```
 
-*If you are unsure whether to install as root or a local user, install as a local user.*
+*If you are unsure whether to install as root or a local user, install
+ as a local user.*
 
 
 Installation from source
@@ -76,12 +78,20 @@ Common Issues:
 $ meson builddir
 $ bash: /usr/bin/meson: No such file or directory
 ```
-Description: The default installation prefix for the python pip module installation is not included in your shell environment PATH. The default prefix for python pip installation modules is located under ``/usr/local``.
+
+Description: The default installation prefix for the python pip module
+installation is not included in your shell environment PATH. The
+default prefix for python pip installation modules is located under
+``/usr/local``.
 
 **Resolution:
-This issue can be resolved by altering the default shell environment PATH to include ``/usr/local/bin``. **
+This issue can be resolved by altering the default shell environment
+PATH to include ``/usr/local/bin``. **
 
-*Note: There are other ways of fixing this issue such as using symlinks or copying the binaries to a default path and these methods are not recommended or supported as they may break package management interoperability.*
+*Note: There are other ways of fixing this issue such as using
+ symlinks or copying the binaries to a default path and these methods
+ are not recommended or supported as they may break package management
+ interoperability.*
 
 
 Compiling a Meson project
@@ -99,19 +109,19 @@ $ meson test
 
 The only thing to note is that you need to create a separate build
 directory. Meson will not allow you to build source code inside your
-source tree. All build artifacts are stored in the build
+source tree. All build artifacts are stored in the build directory.
-directory. This allows you to have multiple build trees with different
+This allows you to have multiple build trees with different
 configurations at the same time. This way generated files are not
 added into revision control by accident.
 
-To recompile after code changes, just type `meson compile`. The build command
+To recompile after code changes, just type `meson compile`. The build
-is always the same. You can do arbitrary changes to source code and
+command is always the same. You can do arbitrary changes to source
-build system files and Meson will detect those and will do the right
+code and build system files and Meson will detect those and will do
-thing. If you want to build optimized binaries, just use the argument
+the right thing. If you want to build optimized binaries, just use the
-`--buildtype=debugoptimized` when running Meson. It is recommended
+argument `--buildtype=debugoptimized` when running Meson. It is
-that you keep one build directory for unoptimized builds and one for
+recommended that you keep one build directory for unoptimized builds
-optimized ones. To compile any given configuration, just go into the
+and one for optimized ones. To compile any given configuration, just
-corresponding build directory and run `meson compile`.
+go into the corresponding build directory and run `meson compile`.
 
 Meson will automatically add compiler flags to enable debug
 information and compiler warnings (i.e. `-g` and `-Wall`). This means

docs/markdown/Reference-manual.md

@@ -54,9 +54,9 @@ Like `add_global_arguments` but the arguments are passed to the linker.
   bool add_languages(*langs*)
 ```
 
-Add programming languages used by the project. Equivalent to having them in the
+Add programming languages used by the project. Equivalent to having
-`project` declaration. This function is usually used to add languages that are
+them in the `project` declaration. This function is usually used to
-only used under some conditions, like this:
+add languages that are only used under some conditions, like this:
 
 ```meson
 project('foobar', 'c')
@@ -141,11 +141,12 @@ runtarget alias_target(target_name, dep1, ...)
 
 *(since 0.52.0)*
 
-This function creates a new top-level target. Like all top-level targets, this
+This function creates a new top-level target. Like all top-level
-integrates with the selected backend. For instance, with you can
+targets, this integrates with the selected backend. For instance, with
-run it as `meson compile target_name`. This is a dummy target that does not execute any
+you can run it as `meson compile target_name`. This is a dummy target
-command, but ensures that all dependencies are built. Dependencies can be any
+that does not execute any command, but ensures that all dependencies
-build target (e.g. return value of [executable()](#executable), custom_target(), etc)
+are built. Dependencies can be any build target (e.g. return value of
+[executable()](#executable), custom_target(), etc)
 
 ### assert()
 
@@ -165,13 +166,14 @@ statement instead.
 ```
 
 Creates a benchmark item that will be run when the benchmark target is
-run. The behavior of this function is identical to [`test()`](#test) except for:
+run. The behavior of this function is identical to [`test()`](#test)
+except for:
 
 * benchmark() has no `is_parallel` keyword because benchmarks are not run in parallel
 * benchmark() does not automatically add the `MALLOC_PERTURB_` environment variable
 
-*Note:* Prior to 0.52.0 benchmark would warn that `depends` and `priority`
+*Note:* Prior to 0.52.0 benchmark would warn that `depends` and
-were unsupported, this is incorrect.
+`priority` were unsupported, this is incorrect.
 
 ### both_libraries()
 
@@ -181,9 +183,9 @@ were unsupported, this is incorrect.
 
 *(since 0.46.0)*
 
-Builds both a static and shared library with the given
+Builds both a static and shared library with the given sources.
-sources. Positional and keyword arguments are otherwise the same as
+Positional and keyword arguments are otherwise the same as for
-for [`library`](#library). Source files will be compiled only once and
+[`library`](#library). Source files will be compiled only once and
 object files will be reused to build both shared and static libraries,
 unless `b_staticpic` user option or `pic` argument are set to false in
 which case sources will be compiled twice.
@@ -253,8 +255,8 @@ When a [`configuration_data()`](#configuration_data) object is passed
 to the `configuration:` keyword argument, it takes a template file as
 the `input:` (optional) and produces the `output:` (required) by
 substituting values from the configuration data as detailed in [the
-configuration file documentation](Configuration.md). *(since 0.49.0)* A
+configuration file documentation](Configuration.md). *(since 0.49.0)*
-dictionary can be passed instead of a
+A dictionary can be passed instead of a
 [`configuration_data()`](#configuration_data) object.
 
 When a list of strings is passed to the `command:` keyword argument,
@@ -398,14 +400,15 @@ the following special string substitutions:
 - `@BASENAME@`: the input filename, with extension removed
 - `@PRIVATE_DIR@` *(since 0.50.1)*: path to a directory where the custom target must store all its intermediate files.
 
-*(since 0.47.0)* The `depfile` keyword argument also accepts the `@BASENAME@` and `@PLAINNAME@` substitutions.
+*(since 0.47.0)* The `depfile` keyword argument also accepts the
+ `@BASENAME@` and `@PLAINNAME@` substitutions.
 
 The returned object also has methods that are documented in the
 [object methods section](#custom-target-object) below.
 
-**Note:** Assuming that `command:` is executed by a POSIX `sh` shell is not
+**Note:** Assuming that `command:` is executed by a POSIX `sh` shell
-portable, notably to Windows. Instead, consider using a `native: true`
+is not portable, notably to Windows. Instead, consider using a
-[executable()](#executable), or a python script.
+`native: true` [executable()](#executable), or a python script.
 
 ### declare_dependency()
 
@@ -540,11 +543,11 @@ add CMake `COMPONENTS` for the `find_package` lookup)
 - `disabler` *(since 0.49.0)*: if `true` and the dependency couldn't be found,
   returns a [disabler object](#disabler-object) instead of a not-found dependency.
 
-If dependency_name is `''`, the dependency is always not found.  So
+If dependency_name is `''`, the dependency is always not found. So
 with `required: false`, this always returns a dependency object for
 which the `found()` method returns `false`, and which can be passed
 like any other dependency to the `dependencies:` keyword argument of a
-`build_target`.  This can be used to implement a dependency which is
+`build_target`. This can be used to implement a dependency which is
 sometimes not required e.g. in some branches of a conditional, or with
 a `fallback:` kwarg, can be used to declare an optional dependency
 that only looks in the specified subproject, and only if that's
@@ -606,12 +609,12 @@ libraries (`.so`, `.dll`, etc) will be linked.
 
 With the Ninja backend, Meson will create a build-time [order-only
 dependency](https://ninja-build.org/manual.html#ref_dependencies) on
-all generated input files, including unknown files. This is needed
+all generated input files, including unknown files. This is needed to
-to bootstrap the generation of the real dependencies in the
+bootstrap the generation of the real dependencies in the
-[depfile](https://ninja-build.org/manual.html#ref_headers)
+[depfile](https://ninja-build.org/manual.html#ref_headers) generated
-generated by your compiler to determine when to rebuild sources.
+by your compiler to determine when to rebuild sources. Ninja relies on
-Ninja relies on this dependency file for all input files, generated
+this dependency file for all input files, generated and non-generated.
-and non-generated. The behavior is similar for other backends.
+The behavior is similar for other backends.
 
 Executable supports the following keyword arguments. Note that just
 like the positional arguments above, these keyword arguments can also
@@ -796,9 +799,9 @@ Keyword arguments are the following:
 Meson will also autodetect scripts with a shebang line and run them
 with the executable/interpreter specified in it both on Windows
 (because the command invocator will reject the command otherwise) and
-Unixes (if the script file does not have the executable bit
+Unixes (if the script file does not have the executable bit set).
-set). Hence, you *must not* manually add the interpreter while using
+Hence, you *must not* manually add the interpreter while using this
-this script as part of a list of commands.
+script as part of a list of commands.
 
 If you need to check for a program in a non-standard location, you can
 just pass an absolute path to `find_program`, e.g.
@@ -926,7 +929,8 @@ The only exceptions are: `sysconfdir`, `localstatedir`, and
 configuration as-is, which may be absolute, or relative to `prefix`.
 [`install_dir` arguments](Installing.md) handles that as expected, but
 if you need the absolute path to one of these e.g. to use in a define
-etc., you should use `get_option('prefix') / get_option('localstatedir')`
+etc., you should use `get_option('prefix') /
+get_option('localstatedir')`
 
 For options of type `feature` a
 [feature option object](#feature-option-object)
@@ -1108,8 +1112,7 @@ Accepts the following keywords:
 
 Installs the specified man files from the source tree into system's
 man directory during the install step. This directory can be
-overridden by specifying it with the `install_dir` keyword
+overridden by specifying it with the `install_dir` keyword argument.
-argument.
 
 Accepts the following keywords:
 
@@ -1117,14 +1120,20 @@ Accepts the following keywords:
   format and optionally the owner/uid and group/gid for the installed files.
   An example value could be `['rwxr-sr-x', 'root', 'root']`.
 
-*(since 0.49.0)* [manpages are no longer compressed implicitly][install_man_49].
+*(since 0.49.0)* [manpages are no longer compressed
+ implicitly][install_man_49].
 
-[install_man_49]: https://mesonbuild.com/Release-notes-for-0-49-0.html#manpages-are-no-longer-compressed-implicitly
+[install_man_49]:
+https://mesonbuild.com/Release-notes-for-0-49-0.html#manpages-are-no-longer-compressed-implicitly
 
 ### install_subdir()
 
 ``` meson
-    void install_subdir(subdir_name, install_dir : ..., exclude_files : ..., exclude_directories : ..., strip_directory : ...)
+    void install_subdir(subdir_name,
+                        install_dir : ...,
+                        exclude_files : ...,
+                        exclude_directories : ...,
+                        strip_directory : ...)
 ```
 
 Installs the entire given subdirectory and its contents from the
@@ -1286,8 +1295,8 @@ them for the default behaviour for each platform.
 
 This function prints its argument to stdout.
 
-*(since 0.54.0)* Can take more than one argument that will be separated by
+*(since 0.54.0)* Can take more than one argument that will be
-space.
+separated by space.
 
 ### warning()
 
@@ -1315,19 +1324,21 @@ This function is used to summarize build configuration at the end of the build
 process. This function provides a way for projects (and subprojects) to report
 this information in a clear way.
 
-The content is a series of key/value pairs grouped into sections. If the section
+The content is a series of key/value pairs grouped into sections. If
-keyword argument is omitted, those key/value pairs are implicitly grouped into a section
+the section keyword argument is omitted, those key/value pairs are
-with no title. key/value pairs can optionally be grouped into a dictionary,
+implicitly grouped into a section with no title. key/value pairs can
-but keep in mind that dictionaries does not guarantee ordering. `key` must be string,
+optionally be grouped into a dictionary, but keep in mind that
+dictionaries does not guarantee ordering. `key` must be string,
 `value` can be:
 
 - an integer, boolean or string
 - *since 0.57.0* an external program or a dependency
 - a list of those.
 
-`summary()` can be called multiple times as long as the same section/key
+`summary()` can be called multiple times as long as the same
-pair doesn't appear twice. All sections will be collected and printed at
+section/key pair doesn't appear twice. All sections will be collected
-the end of the configuration in the same order as they have been called.
+and printed at the end of the configuration in the same order as they
+have been called.
 
 Keyword arguments:
 - `section`: title to group a set of key/value pairs.
@@ -1388,10 +1399,10 @@ It may be followed by the list of programming languages that the project uses.
 
 *(since 0.40.0)* The list of languages is optional.
 
-These languages may be used both for `native: false` (the default) (host
+These languages may be used both for `native: false` (the default)
-machine) targets and for `native: true` (build machine) targets. *(since
+(host machine) targets and for `native: true` (build machine) targets.
-0.56.0)* The build machine compilers for the specified languages are not
+*(since 0.56.0)* The build machine compilers for the specified
-required.
+languages are not required.
 
 Supported values for languages are `c`, `cpp` (for `C++`), `cuda`, `d`,
 `objc`, `objcpp`, `fortran`, `java`, `cs` (for `C#`), `vala` and `rust`.
@@ -1442,8 +1453,8 @@ Project supports the following keyword arguments.
     runresult run_command(command, list_of_args, ...)
 ```
 
-Runs the command specified in positional arguments.  `command` can be
+Runs the command specified in positional arguments. `command` can be a
-a string, or the output of [`find_program()`](#find_program),
+string, or the output of [`find_program()`](#find_program),
 [`files()`](#files) or [`configure_file()`](#configure_file), or [a
 compiler object](#compiler-object).
 
@@ -1474,10 +1485,10 @@ runtarget run_target(target_name, ...)
 
 This function creates a new top-level target that runs a specified
 command with the specified arguments. Like all top-level targets, this
-integrates with the selected backend. For instance, you can
+integrates with the selected backend. For instance, you can run it as
-run it as `meson compile target_name`. Note that a run target produces no
+`meson compile target_name`. Note that a run target produces no output
-output as far as Meson is concerned. It is only meant for tasks such
+as far as Meson is concerned. It is only meant for tasks such as
-as running a code formatter or flashing an external device's firmware
+running a code formatter or flashing an external device's firmware
 with a built file.
 
 The command is run from an *unspecified* directory, and Meson will set
@@ -1618,15 +1629,15 @@ This function has one keyword argument.
     subdir_done()
 ```
 
-Stops further interpretation of the meson script file from the point of
+Stops further interpretation of the meson script file from the point
-the invocation. All steps executed up to this point are valid and will
+of the invocation. All steps executed up to this point are valid and
-be executed by meson. This means that all targets defined before the call
+will be executed by meson. This means that all targets defined before
-of `subdir_done` will be build.
+the call of `subdir_done` will be build.
 
-If the current script was called by `subdir` the execution returns to the
+If the current script was called by `subdir` the execution returns to
-calling directory and continues as if the script had reached the end.
+the calling directory and continues as if the script had reached the
-If the current script is the top level script meson configures the project
+end. If the current script is the top level script meson configures
-as defined up to this point.
+the project as defined up to this point.
 
 Example:
 ```meson
@@ -1684,30 +1695,31 @@ argument to [`dependency()`](#dependency).
 
 Defines a test to run with the test harness. Takes two positional
 arguments, the first is the name of the test and the second is the
-executable to run.  The executable can be an [executable build target
+executable to run. The executable can be an [executable build target
 object](#build-target-object) returned by
 [`executable()`](#executable) or an [external program
 object](#external-program-object) returned by
 [`find_program()`](#find_program).
 
-*(since 0.55.0)* When cross compiling, if an exe_wrapper is needed and defined
+*(since 0.55.0)* When cross compiling, if an exe_wrapper is needed and
-the environment variable `MESON_EXE_WRAPPER` will be set to the string value
+defined the environment variable `MESON_EXE_WRAPPER` will be set to
-of that wrapper (implementation detail: using `mesonlib.join_args`). Test
+the string value of that wrapper (implementation detail: using
-scripts may use this to run cross built binaries. If your test needs
+`mesonlib.join_args`). Test scripts may use this to run cross built
-`MESON_EXE_WRAPPER` in cross build situations it is your responsibility to
+binaries. If your test needs `MESON_EXE_WRAPPER` in cross build
-return code 77 to tell the harness to report "skip".
+situations it is your responsibility to return code 77 to tell the
+harness to report "skip".
 
 By default, environment variable
 [`MALLOC_PERTURB_`](http://man7.org/linux/man-pages/man3/mallopt.3.html)
 is automatically set by `meson test` to a random value between 1..255.
 This can help find memory leaks on configurations using glibc,
-including with non-GCC compilers. However, this can have a performance impact,
+including with non-GCC compilers. However, this can have a performance
-and may fail a test due to external libraries whose internals are out of the
+impact, and may fail a test due to external libraries whose internals
-user's control. To check if this feature is causing an expected runtime crash,
+are out of the user's control. To check if this feature is causing an
-disable the feature by temporarily setting environment variable
+expected runtime crash, disable the feature by temporarily setting
-`MALLOC_PERTURB_=0`. While it's preferable to only temporarily disable this
+environment variable `MALLOC_PERTURB_=0`. While it's preferable to
-check, if a project requires permanent disabling of this check
+only temporarily disable this check, if a project requires permanent
-in meson.build do like:
+disabling of this check in meson.build do like:
 
 ```meson
 nomalloc = environment({'MALLOC_PERTURB_': '0'})
@@ -1798,10 +1810,10 @@ result to `output`. This method returns a
 used to signal dependencies if other targets use the file outputted
 by this.
 
-For example, if you generate a header with this and want to use that in
+For example, if you generate a header with this and want to use that
-a build target, you must add the return value to the sources of that
+in a build target, you must add the return value to the sources of
-build target. Without that, Meson will not know the order in which to
+that build target. Without that, Meson will not know the order in
-build the targets.
+which to build the targets.
 
 If you desire more specific behavior than what this command provides,
 you should use `custom_target`.
@@ -2369,11 +2381,12 @@ The following keyword arguments can be used:
   `sizeof`, `has_type`, `has_function`, `has_member`, `has_members`,
   `check_header`, `has_header`, `has_header_symbol`, `get_define`
 
-**Note:** These compiler checks do not use compiler arguments added with
+**Note:** These compiler checks do not use compiler arguments added
-`add_*_arguments()`, via `-Dlang_args` on the command-line, or through
+with `add_*_arguments()`, via `-Dlang_args` on the command-line, or
-`CFLAGS`/`LDFLAGS`, etc in the environment. Hence, you can trust that
+through `CFLAGS`/`LDFLAGS`, etc in the environment. Hence, you can
-the tests will be fully self-contained, and won't fail because of custom
+trust that the tests will be fully self-contained, and won't fail
-flags added by other parts of the build file or by users.
+because of custom flags added by other parts of the build file or by
+users.
 
 Note that if you have a single prefix with all your dependencies, you
 might find it easier to append to the environment variables
@@ -2387,10 +2400,10 @@ cross-compiling. In that case you need to use a specs file. See:
 
 ### `build target` object
 
-A build target is either an [executable](#executable),
+A build target is either an [executable](#executable), [shared
-[shared library](#shared_library), [static library](#static_library),
+library](#shared_library), [static library](#static_library), [both
-[both shared and static library](#both_libraries) or
+shared and static library](#both_libraries) or [shared
-[shared module](#shared_module).
+module](#shared_module).
 
 - `extract_all_objects()`: is same as `extract_objects` but returns all
   object files generated by this target. *(since 0.46.0)* keyword argument

docs/markdown/Reference-tables.md

@@ -159,20 +159,21 @@ These are the parameter names for passing language specific arguments to your bu
 | Rust          | rust_args     | rust_link_args    |
 | Vala          | vala_args     | vala_link_args    |
 
-All these `<lang>_*` options are specified per machine. See in [specifying
+All these `<lang>_*` options are specified per machine. See in
-options per machine](Builtin-options.md#Specifying-options-per-machine) for on
+[specifying options per
-how to do this in cross builds.
+machine](Builtin-options.md#Specifying-options-per-machine) for on how
+to do this in cross builds.
 
 ## Compiler and linker flag environment variables
 
 These environment variables will be used to modify the compiler and
 linker flags.
 
-It is recommended that you **do not use these**. They are provided purely to
+It is recommended that you **do not use these**. They are provided
-for backwards compatibility with other build systems. There are many caveats to
+purely to for backwards compatibility with other build systems. There
-their use, especially when rebuilding the project. It is **highly** recommended
+are many caveats to their use, especially when rebuilding the project.
-that you use [the command line arguments](#language-arguments-parameter-names)
+It is **highly** recommended that you use [the command line
-instead.
+arguments](#language-arguments-parameter-names) instead.
 
 | Name      | Comment                                  |
 | -----     | -------                                  |
@@ -185,8 +186,8 @@ instead.
 | RUSTFLAGS | Flags for the Rust compiler              |
 | LDFLAGS   | The linker flags, used for all languages |
 
-N.B. these settings are specified per machine, and so the environment varibles
+N.B. these settings are specified per machine, and so the environment
-actually come in pairs. See the [environment variables per
+varibles actually come in pairs. See the [environment variables per
 machine](#Environment-variables-per-machine) section for details.
 
 ## Function Attributes
@@ -282,8 +283,8 @@ These are the values that can be passed to `dependency` function's
 
 ## Compiler and Linker selection variables
 
-N.B. these settings are specified per machine, and so the environment varibles
+N.B. these settings are specified per machine, and so the environment
-actually come in pairs. See the [environment variables per
+varibles actually come in pairs. See the [environment variables per
 machine](#Environment-variables-per-machine) section for details.
 
 | Language      | Compiler | Linker    | Note                                        |
@@ -298,16 +299,17 @@ machine](#Environment-variables-per-machine) section for details.
 | Vala          | VALAC    |           | Use CC_LD. Vala transpiles to C             |
 | C#            | CSC      | CSC       | The linker is the compiler                  |
 
-*The old environment variales are still supported, but are deprecated and will
+*The old environment variales are still supported, but are deprecated
-be removed in a future version of meson.*
+and will be removed in a future version of meson.*
 
 ## Environment variables per machine
 
-Since *0.54.0*, Following Autotool and other legacy build systems, environment
+Since *0.54.0*, Following Autotool and other legacy build systems,
-variables that affect machine-specific settings come in pairs: for every bare
+environment variables that affect machine-specific settings come in
-environment variable `FOO`, there is a suffixed `FOO_FOR_BUILD`, where `FOO`
+pairs: for every bare environment variable `FOO`, there is a suffixed
-just affects the host machine configuration, while `FOO_FOR_BUILD` just affects
+`FOO_FOR_BUILD`, where `FOO` just affects the host machine
-the build machine configuration. For example:
+configuration, while `FOO_FOR_BUILD` just affects the build machine
+configuration. For example:
 
  - `PKG_CONFIG_PATH_FOR_BUILD` controls the paths pkg-config will search for
    just `native: true` dependencies (build machine).
@@ -315,12 +317,13 @@ the build machine configuration. For example:
  - `PKG_CONFIG_PATH` controls the paths pkg-config will search for just
    `native: false` dependencies (host machine).
 
-This mirrors the `build.` prefix used for (built-in) meson options, which has
+This mirrors the `build.` prefix used for (built-in) meson options,
-the same meaning.
+which has the same meaning.
 
-This is useful for cross builds. In the native builds, build = host, and the
+This is useful for cross builds. In the native builds, build = host,
-unsuffixed environment variables alone will suffice.
+and the unsuffixed environment variables alone will suffice.
 
-Prior to *0.54.0*, there was no `_FOR_BUILD`-suffixed variables, and most
+Prior to *0.54.0*, there was no `_FOR_BUILD`-suffixed variables, and
-environment variables only effected native machine configurations, though this
+most environment variables only effected native machine
-wasn't consistent (e.g. `PKG_CONFIG_PATH` still affected cross builds).
+configurations, though this wasn't consistent (e.g. `PKG_CONFIG_PATH`
+still affected cross builds).

docs/markdown/Release-notes-for-0.37.0.md

@@ -7,7 +7,8 @@ short-description: Release notes for 0.37
 
 ## Mesontest
 
-Mesontest is a new testing tool that allows you to run your tests in many different ways. As an example you can run tests multiple times:
+Mesontest is a new testing tool that allows you to run your tests in
+many different ways. As an example you can run tests multiple times:
 
     mesontest --repeat=1000 a_test
 
@@ -15,13 +16,17 @@ or with an arbitrary wrapper executable:
 
     mesontest --wrap='valgrind --tool=helgrind' a_test
 
-or under `gdb`, 1000 times in a row. This is handy for tests that fail spuriously, as when the crash happens you are given the full GDB command line:
+or under `gdb`, 1000 times in a row. This is handy for tests that fail
+spuriously, as when the crash happens you are given the full GDB
+command line:
 
     mesontest --repeat=1000 --gdb a_test
 
 ## Mesonrewriter
 
-Mesonrewriter is an experimental tool to manipulate your build definitions programmatically. It is not installed by default yet but those interested can run it from the source repository.
+Mesonrewriter is an experimental tool to manipulate your build
+definitions programmatically. It is not installed by default yet but
+those interested can run it from the source repository.
 
 As an example, here is how you would add a source file to a build target:
 
@@ -29,7 +34,9 @@ As an example, here is how you would add a source file to a build target:
 
 ## Shared modules
 
-The new `shared_module` function allows the creation of shared modules, that is, extension modules such as plugins that are meant to be used solely with `dlopen` rather than linking them to targets.
+The new `shared_module` function allows the creation of shared
+modules, that is, extension modules such as plugins that are meant to
+be used solely with `dlopen` rather than linking them to targets.
 
 ## Gnome module
 
@@ -56,21 +63,32 @@ The new `shared_module` function allows the creation of shared modules, that is,
 
 ## LLVM IR compilation
 
-Meson has long had support for compiling assembler (GAS) files. In this release we add support for compiling LLVM IR files in a similar way when building with the Clang compiler. Just add it to the list of files when creating a `library` or `executable` target like any other source file. No special handling is required:
+Meson has long had support for compiling assembler (GAS) files. In
+this release we add support for compiling LLVM IR files in a similar
+way when building with the Clang compiler. Just add it to the list of
+files when creating a `library` or `executable` target like any other
+source file. No special handling is required:
 
 ```meson
 executable('some-exe', 'main.c', 'asm-file.S', 'ir-file.ll')
 ```
 
-As always, you can also mix LLVM IR files with C++, C, and Assembly (GAS) sources.
+As always, you can also mix LLVM IR files with C++, C, and Assembly
+(GAS) sources.
 
 ## ViM indent and syntax files
 
-We now include filetype, indent, and syntax files for ViM [with the source tree](https://github.com/mesonbuild/meson/tree/master/data/syntax-highlighting/vim). Please file issues (or pull requests!) for enhancements or if you face any problems using them.
+We now include filetype, indent, and syntax files for ViM [with the
+source
+tree](https://github.com/mesonbuild/meson/tree/master/data/syntax-highlighting/vim).
+Please file issues (or pull requests!) for enhancements or if you face
+any problems using them.
 
 ## Push URLs in .wrap files
 
-[.wrap files](Using-the-WrapDB.md) for subprojects can now include a separate push URL to allow developers to push changes directly from a subproject git checkout.
+[.wrap files](Using-the-WrapDB.md) for subprojects can now include a
+separate push URL to allow developers to push changes directly from a
+subproject git checkout.
 
 ## pkg-config dependencies
 
@@ -87,7 +105,8 @@ dependency('foolite', version : ['>=3.12.1', '!=3.13.99'])
 
 ## Overriding more binaries with environment variables
 
-You can now specify the binary to be used for the following tools by setting the corresponding environment variable
+You can now specify the binary to be used for the following tools by
+setting the corresponding environment variable
 
 | Name | Environment variable |
 | ---- | -------------------- |
@@ -97,11 +116,18 @@ You can now specify the binary to be used for the following tools by setting the
 
 ## Support for `localstatedir`
 
-Similar to other options such as `bindir` and `datadir`, you can now specify the `localstatedir` for a project by passing `--localstatedir=dir` to `meson` or `-Dlocalstatedir=dir` to `mesonconf` after configuration. You can also access it from inside the `meson.build` file with `get_option('localstatedir')`.
+Similar to other options such as `bindir` and `datadir`, you can now
+specify the `localstatedir` for a project by passing
+`--localstatedir=dir` to `meson` or `-Dlocalstatedir=dir` to
+`mesonconf` after configuration. You can also access it from inside
+the `meson.build` file with `get_option('localstatedir')`.
 
 ## New compiler function `symbols_have_underscore_prefix`
 
-Checks if the compiler prefixes an underscore to C global symbols with the default calling convention. This is useful when linking to compiled assembly code, or other code that does not have its C symbol mangling handled transparently by the compiler.
+Checks if the compiler prefixes an underscore to C global symbols with
+the default calling convention. This is useful when linking to
+compiled assembly code, or other code that does not have its C symbol
+mangling handled transparently by the compiler.
 
 ```meson
 cc = meson.get_compiler('c')
@@ -111,18 +137,37 @@ if cc.symbols_have_underscore_prefix()
 endif
 ```
 
-C symbol mangling is platform and architecture dependent, and a helper function is needed to detect it. For example, Windows 32-bit prefixes underscore, but 64-bit does not. Linux does not prefix an underscore but OS X does.
+C symbol mangling is platform and architecture dependent, and a helper
+function is needed to detect it. For example, Windows 32-bit prefixes
+underscore, but 64-bit does not. Linux does not prefix an underscore
+but OS X does.
 
 ## Vala
 
-GLib Resources compiled with [`gnome.compile_resources`](Gnome-module.md#compile_resources) that are added to the sources of a Vala build target will now cause the appropriate `--gresources` flag to be passed to the Vala compiler so you don't need to add that yourself to `vala_args:`.
+GLib Resources compiled with
+[`gnome.compile_resources`](Gnome-module.md#compile_resources) that
+are added to the sources of a Vala build target will now cause the
+appropriate `--gresources` flag to be passed to the Vala compiler so
+you don't need to add that yourself to `vala_args:`.
 
 ## Improvements to install scripts
 
-You can now pass arguments to install scripts added with [`meson.add_install_script()`](Reference-manual.md#meson-object). All arguments after the script name will be passed to the script.
+You can now pass arguments to install scripts added with
-
+[`meson.add_install_script()`](Reference-manual.md#meson-object). All
-The `MESON_INSTALL_DESTDIR_PREFIX` environment variable is now set when install scripts are called. This contains the values of the `DESTDIR` environment variable and the `prefix` option passed to Meson joined together. This is useful because both those are usually absolute paths, and joining absolute paths in a cross-platform way is tricky. [`os.path.join` in Python](https://docs.python.org/3/library/os.path.html#os.path.join) will discard all previous path segments when it encounters an absolute path, and simply concatenating them will not work on Windows where absolute paths begin with the drive letter.
+arguments after the script name will be passed to the script.
+
+The `MESON_INSTALL_DESTDIR_PREFIX` environment variable is now set
+when install scripts are called. This contains the values of the
+`DESTDIR` environment variable and the `prefix` option passed to Meson
+joined together. This is useful because both those are usually
+absolute paths, and joining absolute paths in a cross-platform way is
+tricky. [`os.path.join` in
+Python](https://docs.python.org/3/library/os.path.html#os.path.join)
+will discard all previous path segments when it encounters an absolute
+path, and simply concatenating them will not work on Windows where
+absolute paths begin with the drive letter.
 
 ## More install directories
 
-Added new options `sbindir` and `infodir` that can be used for installation.
+Added new options `sbindir` and `infodir` that can be used for
+installation.

docs/markdown/Release-notes-for-0.38.0.md

@@ -5,11 +5,19 @@ short-description: Release notes for 0.38
 
 ## Uninstall target
 
-Meson allows you to uninstall an install step by invoking the uninstall target. This will remove all files installed as part of install. Note that this does not restore the original files. This also does not undo changes done by custom install scripts (because they can do arbitrary install operations).
+Meson allows you to uninstall an install step by invoking the
+uninstall target. This will remove all files installed as part of
+install. Note that this does not restore the original files. This also
+does not undo changes done by custom install scripts (because they can
+do arbitrary install operations).
 
 ## Support for arbitrary test setups
 
-Sometimes you need to run unit tests with special settings. For example under Valgrind. Usually this requires extra command line options for the tool. This is supported with the new *test setup* feature. For example to set up a test run with Valgrind, you'd write this in a `meson.build` file:
+Sometimes you need to run unit tests with special settings. For
+example under Valgrind. Usually this requires extra command line
+options for the tool. This is supported with the new *test setup*
+feature. For example to set up a test run with Valgrind, you'd write
+this in a `meson.build` file:
 
 ```meson
 add_test_setup('valgrind',
@@ -17,7 +25,9 @@ add_test_setup('valgrind',
   timeout_multiplier : 100)
 ```
 
-This tells Meson to run tests with Valgrind using the given options and multiplying the test timeout values by 100. To run this test setup simply issue the following command:
+This tells Meson to run tests with Valgrind using the given options
+and multiplying the test timeout values by 100. To run this test setup
+simply issue the following command:
 
 ```console
 $ mesontest --setup=valgrind
@@ -25,11 +35,13 @@ $ mesontest --setup=valgrind
 
 ## Intel C/C++ compiler support
 
-As usual, just set `CC=icc CXX=icpc` and Meson will use it as the C/C++ compiler. Currently only Linux is supported.
+As usual, just set `CC=icc CXX=icpc` and Meson will use it as the
+C/C++ compiler. Currently only Linux is supported.
 
 ## Get values from configuration data objects
 
-Now it is possible to query values stored in configuration data objects.
+Now it is possible to query values stored in configuration data
+objects.
 
 ```meson
 cdata.set('key', 'value')
@@ -40,7 +52,8 @@ cdata.get('nokey') # halts with an error
 
 ## Python 3 module support
 
-Building Python 3 extension modules has always been possible, but it is now even easier:
+Building Python 3 extension modules has always been possible, but it
+is now even easier:
 
 ```meson
 py3_mod = import('python3')
@@ -51,34 +64,51 @@ pylib = py3_mod.extension_module('modname',
 
 ## Default options to subprojects
 
-Projects can specify overriding values for subprojects' `default_options` when invoking a subproject:
+Projects can specify overriding values for subprojects'
+`default_options` when invoking a subproject:
 
 ```meson
 subproject('foo', default_options : ['optname=overridevalue'])
 dependency('some-dep', fallback : ['some_subproject', 'some_dep'], default_options : ['optname=overridevalue'])
 ```
 
-The effect is the same as if the default options were written in the subproject's `project` call.
+The effect is the same as if the default options were written in the
+subproject's `project` call.
 
 ## Set targets to be built (or not) by default
 
-Build targets got a new keyword `build_by_default` which tells whether the target should be built by default when running e.g. `ninja`. Custom targets are not built by default but other targets are. Any target that is tagged as installed or to be built always is also built by default, regardless of the value of this keyword.
+Build targets got a new keyword `build_by_default` which tells whether
+the target should be built by default when running e.g. `ninja`.
+Custom targets are not built by default but other targets are. Any
+target that is tagged as installed or to be built always is also built
+by default, regardless of the value of this keyword.
 
 ## Add option to mesonconf to wipe cached data.
 
-Meson caches the results of dependency lookups. Sometimes these may get out of sync with the system state. Mesonconf now has a `--clearcache` option to clear these values so they will be re-searched from the system upon next compile.
+Meson caches the results of dependency lookups. Sometimes these may
+get out of sync with the system state. Mesonconf now has a
+`--clearcache` option to clear these values so they will be
+re-searched from the system upon next compile.
 
 ## Can specify file permissions and owner when installing data
 
-The new `install_mode` keyword argument can be used to specify file permissions and uid/gid of files when doing the install. This allows you to, for example, install suid root scripts.
+The new `install_mode` keyword argument can be used to specify file
+permissions and uid/gid of files when doing the install. This allows
+you to, for example, install suid root scripts.
 
 ## `has_header()` checks are now faster
 
-When using compilers that implement the [`__has_include()` preprocessor macro](https://clang.llvm.org/docs/LanguageExtensions.html#include-file-checking-macros), the check is now ~40% faster.
+When using compilers that implement the [`__has_include()`
+preprocessor
+macro](https://clang.llvm.org/docs/LanguageExtensions.html#include-file-checking-macros),
+the check is now ~40% faster.
 
 ## Array indexing now supports fallback values
 
-The second argument to the array [`.get()`](Reference-manual.md#array-object) function is now returned if the specified index could not be found
+The second argument to the array
+[`.get()`](Reference-manual.md#array-object) function is now returned
+if the specified index could not be found
+
 ```meson
 array = [10, 11, 12, 13]
 array.get(0) # this will return `10`
@@ -88,4 +118,6 @@ array.get(4, 0) # this will return `0`
 
 ## Silent mode for Mesontest
 
-The Meson test executor got a new argument `-q` (and `--quiet`) that suppresses all output of successful tests. This makes interactive usage nicer because only errors are printed.
+The Meson test executor got a new argument `-q` (and `--quiet`) that
+suppresses all output of successful tests. This makes interactive
+usage nicer because only errors are printed.

docs/markdown/Release-notes-for-0.39.0.md

@@ -3,12 +3,14 @@ title: Release 0.39
 short-description: Release notes for 0.39
 ...
 
-The 0.39.0 release turned out to consist almost entirely of bug fixes and minor polishes.
+The 0.39.0 release turned out to consist almost entirely of bug fixes
+and minor polishes.
 
 # New features
 
 ## Extra arguments for tests
 
-The Meson test executable allows specifying extra command line arguments to pass to test executables.
+The Meson test executable allows specifying extra command line
+arguments to pass to test executables.
 
     mesontest --test-args=--more-debug-info currenttest

docs/markdown/Release-notes-for-0.40.0.md

@@ -7,11 +7,13 @@ short-description: Release notes for 0.40
 
 ## Outputs of generators can be used in custom targets in the VS backend
 
-This has been possible with the Ninja backend for a long time but now the Visual Studio backend works too.
+This has been possible with the Ninja backend for a long time but now
+the Visual Studio backend works too.
 
 ## `compute_int` method in the compiler objects
 
-This method can be used to evaluate the value of an expression. As an example:
+This method can be used to evaluate the value of an expression. As an
+example:
 
 ```meson
 cc = meson.get_compiler('c')
@@ -20,29 +22,44 @@ two = cc.compute_int('1 + 1') # A very slow way of adding two numbers.
 
 ## Visual Studio 2017 support
 
-There is now a VS2017 backend (`--backend=vs2017`) as well as a generic VS backend (`--backend=vs`) that autodetects the currently active VS version.
+There is now a VS2017 backend (`--backend=vs2017`) as well as a
+generic VS backend (`--backend=vs`) that autodetects the currently
+active VS version.
 
 ## Automatic initialization of subprojects that are git submodules
 
-If you have a directory inside your subprojects directory (usually `subprojects/`) that is a git submodule, meson will automatically initialize it if your build files refer to it. This will be done without needing a wrap file since git contains all the information needed.
+If you have a directory inside your subprojects directory (usually
+`subprojects/`) that is a git submodule, meson will automatically
+initialize it if your build files refer to it. This will be done
+without needing a wrap file since git contains all the information
+needed.
 
 ## No download mode for wraps
 
-Added a new option `wrap-mode` that can be toggled to prevent Meson from downloading dependency projects. Attempting to do so will cause an error. This is useful for distro packagers and other cases where you must explicitly enforce that nothing is downloaded from the net during configuration or build.
+Added a new option `wrap-mode` that can be toggled to prevent Meson
+from downloading dependency projects. Attempting to do so will cause
+an error. This is useful for distro packagers and other cases where
+you must explicitly enforce that nothing is downloaded from the net
+during configuration or build.
 
 ## Overriding options per target
 
-Build targets got a new keyword argument `override_options` that can be used to override system options. As an example if you have a target that you know can't be built with `-Werror` enabled you can override the value of the option like this:
+Build targets got a new keyword argument `override_options` that can
+be used to override system options. As an example if you have a target
+that you know can't be built with `-Werror` enabled you can override
+the value of the option like this:
 
 ```meson
 executable('foo', 'foo.c', override_options : ['werror=false'])
 ```
 
-Note that this does not affect project options, only those options that come from Meson (language standards, unity builds etc).
+Note that this does not affect project options, only those options
+that come from Meson (language standards, unity builds etc).
 
 ## Compiler object get define
 
-Compiler objects got a new method `get_define()` that returns the given preprocessor symbol as a string.
+Compiler objects got a new method `get_define()` that returns the
+given preprocessor symbol as a string.
 
 ```meson
 cc = meson.get_compiler('c')
@@ -51,11 +68,14 @@ one = cc.get_define('__linux__') # returns '1' on Linux hosts
 
 ## Cygwin support
 
-Meson now works under Cygwin and we have added it to our CI test matrix.
+Meson now works under Cygwin and we have added it to our CI test
+matrix.
 
 ## Multiple install directories
 
-Custom targets can produce many output files. Previously it was only possible to install all of them in the same directory, but now you can install each output in its own directory like this:
+Custom targets can produce many output files. Previously it was only
+possible to install all of them in the same directory, but now you can
+install each output in its own directory like this:
 
 ```meson
 custom_target('two_out',
@@ -65,9 +85,13 @@ custom_target('two_out',
   install_dir : ['dir1', 'dir2'])
 ```
 
-For backwards compatibility and for conciseness, if you only specify one directory all outputs will be installed into it.
+For backwards compatibility and for conciseness, if you only specify
+one directory all outputs will be installed into it.
 
-The same feature is also available for Vala build targets. For instance, to install a shared library built by valac, the generated header, and the generated VAPI (respectively) into the default locations, you can do:
+The same feature is also available for Vala build targets. For
+instance, to install a shared library built by valac, the generated
+header, and the generated VAPI (respectively) into the default
+locations, you can do:
 
 ```meson
 shared_library('valalib', 'mylib.vala',
@@ -75,11 +99,18 @@ shared_library('valalib', 'mylib.vala',
   install_dir : [true, true, true])
 ```
 
-To install any of the three in a custom directory, just pass it as a string instead of `true`. To not install it, pass `false`. You can also pass a single string (as before) and it will cause only the library to be installed, so this is a backwards-compatible change.
+To install any of the three in a custom directory, just pass it as a
+string instead of `true`. To not install it, pass `false`. You can
+also pass a single string (as before) and it will cause only the
+library to be installed, so this is a backwards-compatible change.
 
 ## Can specify method of obtaining dependencies
 
-Some dependencies have many ways of being provided. As an example Qt can either be detected via `pkg-config` or `qmake`. Until now Meson has had a heuristic for selecting which method to choose but sometimes it does the wrong thing. This can now be overridden with the `method` keyword like this:
+Some dependencies have many ways of being provided. As an example Qt
+can either be detected via `pkg-config` or `qmake`. Until now Meson
+has had a heuristic for selecting which method to choose but sometimes
+it does the wrong thing. This can now be overridden with the `method`
+keyword like this:
 
 ```meson
 qt5_dep = dependency('qt5', modules : 'core', method : 'qmake')
@@ -87,20 +118,35 @@ qt5_dep = dependency('qt5', modules : 'core', method : 'qmake')
 
 ## Link whole contents of static libraries
 
-The default behavior of static libraries is to discard all symbols that are not not directly referenced. This may lead to exported symbols being lost. Most compilers support "whole archive" linking that includes all symbols and code of a given static library. This is exposed with the `link_whole` keyword.
+The default behavior of static libraries is to discard all symbols
+that are not not directly referenced. This may lead to exported
+symbols being lost. Most compilers support "whole archive" linking
+that includes all symbols and code of a given static library. This is
+exposed with the `link_whole` keyword.
 
 ```meson
 shared_library('foo', 'foo.c', link_whole : some_static_library)
 ```
 
-Note that Visual Studio compilers only support this functionality on VS 2015 and newer.
+Note that Visual Studio compilers only support this functionality on
+VS 2015 and newer.
 
 ## Unity builds only for subprojects
 
-Up until now unity builds were either done for every target or none of them. Now unity builds can be specified to be enabled only for subprojects, which change seldom, and not for the master project, which changes a lot. This is enabled by setting the `unity` option to `subprojects`.
+Up until now unity builds were either done for every target or none of
+them. Now unity builds can be specified to be enabled only for
+subprojects, which change seldom, and not for the master project,
+which changes a lot. This is enabled by setting the `unity` option to
+`subprojects`.
 
 ## Running `mesonintrospect` from scripts
 
-Meson now sets the `MESONINTROSPECT` environment variable in addition to `MESON_SOURCE_ROOT` and other variables when running scripts. It is guaranteed to point to the correct `mesonintrospect` script, which is important when running meson uninstalled from git or when your `PATH`s may not be set up correctly.
+Meson now sets the `MESONINTROSPECT` environment variable in addition
+to `MESON_SOURCE_ROOT` and other variables when running scripts. It is
+guaranteed to point to the correct `mesonintrospect` script, which is
+important when running meson uninstalled from git or when your `PATH`s
+may not be set up correctly.
 
-Specifically, the following meson functions will set it: `meson.add_install_script()`, `meson.add_postconf_script()`, `run_command()`, `run_target()`.
+Specifically, the following meson functions will set it:
+`meson.add_install_script()`, `meson.add_postconf_script()`,
+`run_command()`, `run_target()`.

docs/markdown/Release-notes-for-0.41.0.md

@@ -11,15 +11,15 @@ Native support for linking against LLVM using the `dependency` function.
 
 ## vcs_tag keyword fallback is now optional
 
-The `fallback` keyword in `vcs_tag()` is now optional. If not given, its value
+The `fallback` keyword in `vcs_tag()` is now optional. If not given,
-defaults to the return value of `meson.project_version()`.
+its value defaults to the return value of `meson.project_version()`.
 
 ## Better quoting of special characters in ninja command invocations
 
-The ninja backend now quotes special characters that may be interpreted by
+The ninja backend now quotes special characters that may be
-ninja itself, providing better interoperability with custom commands. This
+interpreted by ninja itself, providing better interoperability with
-support may not be perfect; please report any issues found with special
+custom commands. This support may not be perfect; please report any
-characters to the issue tracker.
+issues found with special characters to the issue tracker.
 
 ## Pkgconfig support for custom variables
 

docs/markdown/Release-notes-for-0.42.0.md

@@ -7,19 +7,20 @@ short-description: Release notes for 0.42
 
 ## Distribution tarballs from Mercurial repositories
 
-Creating distribution tarballs can now be made out of projects based on
+Creating distribution tarballs can now be made out of projects based
-Mercurial. As before, this remains possible only with the Ninja backend.
+on Mercurial. As before, this remains possible only with the Ninja
+backend.
 
 ## Keyword argument verification
 
-Meson will now check the keyword arguments used when calling any function
+Meson will now check the keyword arguments used when calling any
-and print a warning if any of the keyword arguments is not known. In the
+function and print a warning if any of the keyword arguments is not
-future this will become a hard error.
+known. In the future this will become a hard error.
 
 ## Add support for Genie to Vala compiler
 
-The Vala compiler has an alternative syntax, Genie, that uses the `.gs`
+The Vala compiler has an alternative syntax, Genie, that uses the
-file extension. Meson now recognises and uses Genie files.
+`.gs` file extension. Meson now recognises and uses Genie files.
 
 ## Pkgconfig support for additional cflags
 
@@ -47,8 +48,8 @@ uses_lto = get_option('b_lto')
 Rust targets now take an optional `rust_crate_type` keyword, allowing
 you to set the crate type of the resulting artifact. Valid crate types
 are `dylib` or `cdylib` for shared libraries, and `rlib` or
-`staticlib` for static libraries. For more, see
+`staticlib` for static libraries. For more, see Rust's [linkage
-Rust's [linkage reference][rust-linkage].
+reference][rust-linkage].
 
 [rust-linkage]: https://doc.rust-lang.org/reference/linkage.html
 

docs/markdown/Release-notes-for-0.43.0.md

@@ -5,11 +5,12 @@ short-description: Release notes for 0.43
 
 ## Portability improvements to Boost Dependency
 
-The Boost dependency has been improved to better detect the various ways to
+The Boost dependency has been improved to better detect the various
-install boost on multiple platforms. At the same time the `modules` semantics
+ways to install boost on multiple platforms. At the same time the
-for the dependency has been changed. Previously it was allowed to specify
+`modules` semantics for the dependency has been changed. Previously it
-header directories as `modules` but it wasn't required. Now, modules are only
+was allowed to specify header directories as `modules` but it wasn't
-used to specify libraries that require linking.
+required. Now, modules are only used to specify libraries that require
+linking.
 
 This is a breaking change and the fix is to remove all modules that aren't
 found.
@@ -21,10 +22,11 @@ Generators can now be configured to capture the standard output. See
 
 ## Can index CustomTarget objects
 
-The `CustomTarget` object can now be indexed like an array. The resulting
+The `CustomTarget` object can now be indexed like an array. The
-object can be used as a source file for other Targets, this will create a
+resulting object can be used as a source file for other Targets, this
-dependency on the original `CustomTarget`, but will only insert the generated
+will create a dependency on the original `CustomTarget`, but will only
-file corresponding to the index value of the `CustomTarget`'s `output` keyword.
+insert the generated file corresponding to the index value of the
+`CustomTarget`'s `output` keyword.
 
 ```meson
 c = custom_target(
@@ -65,8 +67,8 @@ native_objdump = find_program('objdump', native : true)
 
 ## Easier handling of supported compiler arguments
 
-A common pattern for handling multiple desired compiler arguments, was to
+A common pattern for handling multiple desired compiler arguments, was
-test their presence and add them to an array one-by-one, e.g.:
+to test their presence and add them to an array one-by-one, e.g.:
 
 ```meson
 warning_flags_maybe = [
@@ -83,8 +85,8 @@ endforeach
 cc.add_project_argument(warning_flags)
 ```
 
-A helper has been added for the foreach/has_argument pattern, so you can
+A helper has been added for the foreach/has_argument pattern, so you
-now simply do:
+can now simply do:
 
 ```meson
 warning_flags = [ ... ]
@@ -93,11 +95,11 @@ flags = cc.get_supported_arguments(warning_flags)
 
 ## Better support for shared libraries in non-system paths
 
-Meson has support for prebuilt object files and static libraries.
+Meson has support for prebuilt object files and static libraries. This
-This release adds feature parity to shared libraries that are either
+release adds feature parity to shared libraries that are either in
-in non-standard system paths or shipped as part of your project. On
+non-standard system paths or shipped as part of your project. On
-systems that support rpath, Meson automatically adds rpath entries
+systems that support rpath, Meson automatically adds rpath entries to
-to built targets using manually found external libraries.
+built targets using manually found external libraries.
 
 This means that e.g. supporting prebuilt libraries shipped with your
 source or provided by subprojects or wrap definitions by writing a
@@ -117,7 +119,7 @@ Then you can use the dependency object in the same way as any other.
 ## wrap-svn
 
 The [Wrap dependency system](Wrap-dependency-system-manual.md) now
-supports [Subversion](https://subversion.apache.org/) (svn).  This
+supports [Subversion](https://subversion.apache.org/) (svn). This
 support is rudimentary. The repository url has to point to a specific
-(sub)directory containing the `meson.build` file (typically
+(sub)directory containing the `meson.build` file (typically `trunk/`).
-`trunk/`). However, providing a `revision` is supported.
+However, providing a `revision` is supported.

docs/markdown/Release-notes-for-0.44.0.md

@@ -7,8 +7,8 @@ short-description: Release notes for 0.44
 
 ## Added warning function
 
-This function prints its argument to the console prefixed by "WARNING:" in
+This function prints its argument to the console prefixed by
-yellow color. A simple example:
+"WARNING:" in yellow color. A simple example:
 
 warning('foo is deprecated, please use bar instead')
 
@@ -31,8 +31,8 @@ These options now default in a way consistent with
 If prefix is `/usr`, default sysconfdir to `/etc`, localstatedir to `/var` and
 sharedstatedir to `/var/lib`.
 
-If prefix is `/usr/local` (the default), default localstatedir to `/var/local`
+If prefix is `/usr/local` (the default), default localstatedir to
-and sharedstatedir to `/var/local/lib`.
+`/var/local` and sharedstatedir to `/var/local/lib`.
 
 
 ## An array type for user options
@@ -57,12 +57,12 @@ meson _build -Darray_opt=two,three
 
 ## LLVM dependency supports both dynamic and static linking
 
-The LLVM dependency has been improved to consistently use dynamic linking.
+The LLVM dependency has been improved to consistently use dynamic
-Previously recent version (>= 3.9) would link dynamically while older versions
+linking. Previously recent version (>= 3.9) would link dynamically
-would link statically.
+while older versions would link statically.
 
-Now LLVM also accepts the `static` keyword to enable statically linking to LLVM
+Now LLVM also accepts the `static` keyword to enable statically
-modules instead of dynamically linking.
+linking to LLVM modules instead of dynamically linking.
 
 
 ## Added `if_found` to subdir
@@ -124,8 +124,8 @@ statements.
 
 ## Config-Tool based dependencies gained a method to get arbitrary options
 
-A number of dependencies (CUPS, LLVM, pcap, WxWidgets, GnuStep) use a config
+A number of dependencies (CUPS, LLVM, pcap, WxWidgets, GnuStep) use a
-tool instead of pkg-config. As of this version they now have a
+config tool instead of pkg-config. As of this version they now have a
 `get_configtool_variable` method, which is analogous to the
 `get_pkgconfig_variable` for pkg config.
 
@@ -136,9 +136,9 @@ llvm_inc_dir = dep_llvm.get_configtool_variable('includedir')
 
 ## Embedded Python in Windows MSI packages
 
-Meson now ships an internal version of Python in the MSI installer packages.
+Meson now ships an internal version of Python in the MSI installer
-This means that it can run Python scripts that are part of your build
+packages. This means that it can run Python scripts that are part of
-transparently. That is, if you do the following:
+your build transparently. That is, if you do the following:
 
 ```meson
 myprog = find_program('myscript.py')
@@ -148,6 +148,7 @@ Then Meson will run the script with its internal Python version if necessary.
 
 ## Libwmf dependency now supports libwmf-config
 
-Earlier, `dependency('libwmf')` could only detect the library with pkg-config
+Earlier, `dependency('libwmf')` could only detect the library with
-files. Now, if pkg-config files are not found, Meson will look for
+pkg-config files. Now, if pkg-config files are not found, Meson will
-`libwmf-config` and if it's found, will use that to find the library.
+look for `libwmf-config` and if it's found, will use that to find the
+library.

docs/markdown/Release-notes-for-0.45.0.md

@@ -96,9 +96,9 @@ int_255 = 0xFF
 
 The value `if-release` can be given for the `b_ndebug` project option.
 
-This will make the `NDEBUG` pre-compiler macro to be defined for release
+This will make the `NDEBUG` pre-compiler macro to be defined for
-type builds as if the `b_ndebug` project option had had the value `true`
+release type builds as if the `b_ndebug` project option had had the
-defined for it.
+value `true` defined for it.
 
 ## `install_data()` defaults to `{datadir}/{projectname}`
 
@@ -128,9 +128,9 @@ returns a list of all licenses for the project.
 ## Rust cross-compilation
 
 Cross-compilation is now supported for Rust targets. Like other
-cross-compilers, the Rust binary must be specified in your cross
+cross-compilers, the Rust binary must be specified in your cross file.
-file. It should specify a `--target` (as installed by `rustup target`)
+It should specify a `--target` (as installed by `rustup target`) and a
-and a custom linker pointing to your C cross-compiler. For example:
+custom linker pointing to your C cross-compiler. For example:
 
 ```ini
 [binaries]
@@ -151,8 +151,8 @@ private sysroot.
 
 ## Project templates
 
-Meson ships with predefined project templates. To start a new project from
+Meson ships with predefined project templates. To start a new project
-scratch, simply go to an empty directory and type:
+from scratch, simply go to an empty directory and type:
 
     meson init --name=myproject --type=executable --language=c
 
@@ -175,11 +175,13 @@ defined in it.
 
 ## Can use custom targets as Windows resource files
 
-The `compile_resources()` function of the `windows` module can now be used on custom targets as well as regular files.
+The `compile_resources()` function of the `windows` module can now be
+used on custom targets as well as regular files.
 
 ## Can promote dependencies with wrap command
 
-The `promote` command makes it easy to copy nested dependencies to the top level.
+The `promote` command makes it easy to copy nested dependencies to the
+top level.
 
     meson wrap promote scommon
 

docs/markdown/Release-notes-for-0.46.0.md

@@ -7,10 +7,11 @@ short-description: Release notes for 0.46
 
 ## Allow early return from a script
 
-Added the function `subdir_done()`. Its invocation exits the current script at
+Added the function `subdir_done()`. Its invocation exits the current
-the point of invocation. All previously invoked build targets and commands are
+script at the point of invocation. All previously invoked build
-build/executed. All following ones are ignored. If the current script was
+targets and commands are build/executed. All following ones are
-invoked via `subdir()` the parent script continues normally.
+ignored. If the current script was invoked via `subdir()` the parent
+script continues normally.
 
 ## Log output slightly changed
 
@@ -20,12 +21,12 @@ adjust your code.
 
 ## ARM compiler for C and CPP
 
-Cross-compilation is now supported for ARM targets using ARM compiler - ARMCC.
+Cross-compilation is now supported for ARM targets using ARM compiler
-The current implementation does not support shareable libraries.
+- ARMCC. The current implementation does not support shareable
-The default extension of the output is .axf.
+libraries. The default extension of the output is .axf. The
-The environment path should be set properly for the ARM compiler executables.
+environment path should be set properly for the ARM compiler
-The '--cpu' option with the appropriate target type should be mentioned
+executables. The '--cpu' option with the appropriate target type
-in the cross file as shown in the snippet below.
+should be mentioned in the cross file as shown in the snippet below.
 
 ```ini
 [properties]
@@ -36,20 +37,20 @@ cpp_args    = ['--cpu=Cortex-M0plus']
 
 ## Building both shared and static libraries
 
-A new function `both_libraries()` has been added to build both shared and static
+A new function `both_libraries()` has been added to build both shared
-libraries at the same time. Source files will be compiled only once and object
+and static libraries at the same time. Source files will be compiled
-files will be reused to build both shared and static libraries, unless
+only once and object files will be reused to build both shared and
-`b_staticpic` user option or `pic:` keyword argument are set to false in which
+static libraries, unless `b_staticpic` user option or `pic:` keyword
-case sources will be compiled twice.
+argument are set to false in which case sources will be compiled
+twice.
 
 The returned `buildtarget` object always represents the shared library.
 
 ## Compiler object can now be passed to run_command()
 
-This can be used to run the current compiler with the specified arguments
+This can be used to run the current compiler with the specified
-to obtain additional information from it.
+arguments to obtain additional information from it. One of the use
-One of the use cases is to get the location of development files for the
+cases is to get the location of development files for the GCC plugins:
-GCC plugins:
 
 ```meson
 cc = meson.get_compiler('c')
@@ -64,25 +65,26 @@ transparently works for build targets which use that dependency.
 
 ## Old command names are now errors
 
-The old executable names `mesonintrospect`, `mesonconf`, `mesonrewriter`
+The old executable names `mesonintrospect`, `mesonconf`,
-and `mesontest` have been deprecated for a long time. Starting from
+`mesonrewriter` and `mesontest` have been deprecated for a long time.
-this version they no longer do anything but instead always error
+Starting from this version they no longer do anything but instead
-out. All functionality is available as subcommands in the main `meson`
+always error out. All functionality is available as subcommands in the
-binary.
+main `meson` binary.
 
 ## Meson and meson configure now accept the same arguments
 
-Previously meson required that builtin arguments (like prefix) be passed as
+Previously meson required that builtin arguments (like prefix) be
-`--prefix` to `meson` and `-Dprefix` to `meson configure`. `meson` now accepts -D
+passed as `--prefix` to `meson` and `-Dprefix` to `meson configure`.
-form like `meson configure` has. `meson configure` also accepts the `--prefix`
+`meson` now accepts -D form like `meson configure` has. `meson
-form, like `meson` has.
+configure` also accepts the `--prefix` form, like `meson` has.
 
 ## Recursively extract objects
 
-The `recursive:` keyword argument has been added to `extract_all_objects()`. When set
+The `recursive:` keyword argument has been added to
-to `true` it will also return objects passed to the `objects:` argument of this
+`extract_all_objects()`. When set to `true` it will also return
-target. By default only objects built for this target are returned to maintain
+objects passed to the `objects:` argument of this target. By default
-backward compatibility with previous versions. The default will eventually be
+only objects built for this target are returned to maintain backward
+compatibility with previous versions. The default will eventually be
 changed to `true` in a future version.
 
 ```meson
@@ -130,8 +132,9 @@ meson.override_find_program('mycodegen', prog_script)
 
 ## New functions: has_link_argument() and friends
 
-A new set of methods has been added to [compiler objects](Reference-manual.md#compiler-object)
+A new set of methods has been added to [compiler
-to test if the linker supports given arguments.
+objects](Reference-manual.md#compiler-object) to test if the linker
+supports given arguments.
 
 - `has_link_argument()`
 - `has_multi_link_arguments()`
@@ -150,9 +153,9 @@ directory called "help" in these cases.
 A feature to generate a meson.build file compiling given C/C++ source
 files into a single executable has been added to "meson init". By
 default, it will take all recognizable source files in the current
-directory.  You can also specify a list of dependencies with the -d
+directory. You can also specify a list of dependencies with the -d
 flag and automatically invoke a build with the -b flag to check if the
-code builds with those dependencies. 
+code builds with those dependencies.
 
 For example,
 
@@ -182,8 +185,9 @@ install_data(['file1.txt', 'file2.txt'],
 ## Support for lcc compiler for e2k (Elbrus) architecture
 
 In this version, a support for lcc compiler for Elbrus processors
-based on [e2k microarchitecture](https://en.wikipedia.org/wiki/Elbrus_2000)
+based on [e2k
-has been added.
+microarchitecture](https://en.wikipedia.org/wiki/Elbrus_2000) has been
+added.
 
 Examples of such CPUs:
 * [Elbrus-8S](https://en.wikipedia.org/wiki/Elbrus-8S);
@@ -206,47 +210,52 @@ So every noted difference is properly handled now in meson.
 ## String escape character sequence update
 
 Single-quoted strings in meson have been taught the same set of escape
-sequences as in Python. It is therefore now possible to use arbitrary bytes in
+sequences as in Python. It is therefore now possible to use arbitrary
-strings, like for example `NUL` (`\0`) and other ASCII control characters. See
+bytes in strings, like for example `NUL` (`\0`) and other ASCII
-the chapter about [*Strings* in *Syntax*](Syntax.md#strings) for more
+control characters. See the chapter about [*Strings* in
-details.
+*Syntax*](Syntax.md#strings) for more details.
 
-Potential backwards compatibility issue: Any valid escape sequence according to
+Potential backwards compatibility issue: Any valid escape sequence
-the new rules will be interpreted as an escape sequence instead of the literal
+according to the new rules will be interpreted as an escape sequence
-characters. Previously only the following escape sequences were supported in
+instead of the literal characters. Previously only the following
-single-quote strings: `\'`, `\\` and `\n`.
+escape sequences were supported in single-quote strings: `\'`, `\\`
+and `\n`.
 
-Note that the behaviour of triple-quoted (multiline) strings has not changed.
+Note that the behaviour of triple-quoted (multiline) strings has not
-They behave like raw strings and do not support any escape sequences.
+changed. They behave like raw strings and do not support any escape
+sequences.
 
 ## New `forcefallback` wrap mode
 
-A new wrap mode was added, `--wrap-mode=forcefallback`. When this is set,
+A new wrap mode was added, `--wrap-mode=forcefallback`. When this is
-dependencies for which a fallback was provided will always use it, even
+set, dependencies for which a fallback was provided will always use
-if an external dependency exists and satisfies the version requirements.
+it, even if an external dependency exists and satisfies the version
+requirements.
 
 ## Relaxing of target name requirements
 
-In earlier versions of Meson you could only have one target of a given name for each type.
+In earlier versions of Meson you could only have one target of a given
-For example you could not have two executables named `foo`. This requirement is now
+name for each type. For example you could not have two executables
-relaxed so that you can have multiple targets with the same name, as long as they are in
+named `foo`. This requirement is now relaxed so that you can have
-different subdirectories.
+multiple targets with the same name, as long as they are in different
+subdirectories.
 
-Note that projects that have multiple targets with the same name can not be built with
+Note that projects that have multiple targets with the same name can
-the `flat` layout or any backend that writes outputs in the same directory.
+not be built with the `flat` layout or any backend that writes outputs
+in the same directory.
 
 ## Addition of OpenMP dependency
 
-An OpenMP dependency (`openmp`) has been added that encapsulates the various
+An OpenMP dependency (`openmp`) has been added that encapsulates the
-flags used by compilers to enable OpenMP and checks for the existence of the
+various flags used by compilers to enable OpenMP and checks for the
-`omp.h` header. The `language` keyword may be passed to force the use of a
+existence of the `omp.h` header. The `language` keyword may be passed
-specific compiler for the checks.
+to force the use of a specific compiler for the checks.
 
 ## Added new partial_dependency method to dependencies and libraries
 
-It is now possible to use only part of a dependency in a target. This allows,
+It is now possible to use only part of a dependency in a target. This
-for example, to only use headers with convenience libraries to avoid linking
+allows, for example, to only use headers with convenience libraries to
-to the same library multiple times.
+avoid linking to the same library multiple times.
 
 ```meson
 dep = dependency('xcb')
@@ -264,22 +273,25 @@ final = shared_library(
 )
 ```
 
-A partial dependency will have the same name version as the full dependency it
+A partial dependency will have the same name version as the full
-is derived from, as well as any values requested.
+dependency it is derived from, as well as any values requested.
 
 ## Improved generation of pkg-config files for static only libraries.
 
-Previously pkg-config files generated by the pkgconfig modules for static libraries
+Previously pkg-config files generated by the pkgconfig modules for
-with dependencies could only be used in a dependencies with `static: true`.
+static libraries with dependencies could only be used in a
+dependencies with `static: true`.
 
-Now the generated file contains the needed dependencies libraries directly within
+Now the generated file contains the needed dependencies libraries
-`Requires` and `Libs` for build static libraries passed via the `libraries` keyword
+directly within `Requires` and `Libs` for build static libraries
-argument.
+passed via the `libraries` keyword argument.
 
-Projects that install both a static and a shared version of a library should use
+Projects that install both a static and a shared version of a library
-the result of [`both_libraries()`](Reference-manual.md#both_libraries) to the
+should use the result of
-pkg-config file generator or use [`configure_file()`](Reference-manual.md#configure_file)
+[`both_libraries()`](Reference-manual.md#both_libraries) to the
-for more complicated setups.
+pkg-config file generator or use
+[`configure_file()`](Reference-manual.md#configure_file) for more
+complicated setups.
 
 ## Improvements to pkgconfig module
 
@@ -298,19 +310,20 @@ pkgconfig.generate(mylib)
 
 ## pkgconfig.generate() requires parameters non-string arguments
 
-`pkgconfig.generate()` `requires:` and `requires_private:` keyword arguments
+`pkgconfig.generate()` `requires:` and `requires_private:` keyword
-now accept pkgconfig-dependencies and libraries that pkgconfig-files were
+arguments now accept pkgconfig-dependencies and libraries that
-generated for.
+pkgconfig-files were generated for.
 
 ## Generic python module
 
-Meson now has is a revamped and generic (python 2 and 3) version of the python3
+Meson now has is a revamped and generic (python 2 and 3) version of
-module. With [this new interface](Python-module.md), projects can now fully
+the python3 module. With [this new interface](Python-module.md),
-specify the version of python they want to build against / install sources to,
+projects can now fully specify the version of python they want to
-and can do so against multiple major or minor versions in parallel.
+build against / install sources to, and can do so against multiple
+major or minor versions in parallel.
 
 ## test() now supports the `depends:` keyword argument
 
-Build targets and custom targets can be listed in the `depends:` keyword argument
+Build targets and custom targets can be listed in the `depends:`
-of test function. These targets will be built before test is run even if they have
+keyword argument of test function. These targets will be built before
-`build_by_default : false`.
+test is run even if they have `build_by_default : false`.

docs/markdown/Release-notes-for-0.47.0.md

@@ -7,32 +7,34 @@ short-description: Release notes for 0.47
 
 ## Allow early return from a script
 
-Added the function `subdir_done()`. Its invocation exits the current script at
+Added the function `subdir_done()`. Its invocation exits the current
-the point of invocation. All previously invoked build targets and commands are
+script at the point of invocation. All previously invoked build
-build/executed. All following ones are ignored. If the current script was
+targets and commands are build/executed. All following ones are
-invoked via `subdir()` the parent script continues normally.
+ignored. If the current script was invoked via `subdir()` the parent
+script continues normally.
 
 ## Concatenate string literals returned from `get_define()`
 
-After obtaining the value of a preprocessor symbol consecutive string literals
+After obtaining the value of a preprocessor symbol consecutive string
-are merged into a single string literal.
+literals are merged into a single string literal. For example a
-For example a preprocessor symbol's value `"ab" "cd"` is returned as `"abcd"`.
+preprocessor symbol's value `"ab" "cd"` is returned as `"abcd"`.
 
 ## ARM compiler(version 6) for C and CPP
 
 Cross-compilation is now supported for ARM targets using ARM compiler
-version 6 - ARMCLANG.  The required ARMCLANG compiler options for
+version 6 - ARMCLANG. The required ARMCLANG compiler options for
 building a shareable library are not included in the current Meson
 implementation for ARMCLANG support, so it can not build shareable
-libraries.  This current Meson implementation for ARMCLANG support can
+libraries. This current Meson implementation for ARMCLANG support can
-not build assembly files with arm syntax (we need to use armasm instead
+not build assembly files with arm syntax (we need to use armasm
-of ARMCLANG for the `.s` files with this syntax) and only supports GNU
+instead of ARMCLANG for the `.s` files with this syntax) and only
-syntax.
+supports GNU syntax.
 
-The default extension of the executable output is `.axf`.
+The default extension of the executable output is `.axf`. The
-The environment path should be set properly for the ARM compiler executables.
+environment path should be set properly for the ARM compiler
-The `--target`, `-mcpu` options with the appropriate values should be mentioned
+executables. The `--target`, `-mcpu` options with the appropriate
-in the cross file as shown in the snippet below.
+values should be mentioned in the cross file as shown in the snippet
+below.
 
 ```ini
 [properties]
@@ -48,61 +50,63 @@ Note:
 
 ## New base build option for LLVM (Apple) bitcode support
 
-When building with clang on macOS, you can now build your static and shared
+When building with clang on macOS, you can now build your static and
-binaries with embedded bitcode by enabling the `b_bitcode` [base
+shared binaries with embedded bitcode by enabling the `b_bitcode`
-option](Builtin-options.md#base-options) by passing `-Db_bitcode=true` to
+[base option](Builtin-options.md#base-options) by passing
-Meson.
+`-Db_bitcode=true` to Meson.
 
-This is better than passing the options manually in the environment since Meson
+This is better than passing the options manually in the environment
-will automatically disable conflicting options such as `b_asneeded`, and will
+since Meson will automatically disable conflicting options such as
-disable bitcode support on targets that don't support it such as
+`b_asneeded`, and will disable bitcode support on targets that don't
-`shared_module()`.
+support it such as `shared_module()`.
 
-Since this requires support in the linker, it is currently only enabled when
+Since this requires support in the linker, it is currently only
-using Apple ld. In the future it can be extended to clang on other platforms
+enabled when using Apple ld. In the future it can be extended to clang
-too.
+on other platforms too.
 
 ## New compiler check: `check_header()`
 
-The existing compiler check `has_header()` only checks if the header exists,
+The existing compiler check `has_header()` only checks if the header
-either with the `__has_include` C++11 builtin, or by running the pre-processor.
+exists, either with the `__has_include` C++11 builtin, or by running
+the pre-processor.
 
-However, sometimes the header you are looking for is unusable on some platforms
+However, sometimes the header you are looking for is unusable on some
-or with some compilers in a way that is only detectable at compile-time. For
+platforms or with some compilers in a way that is only detectable at
-such cases, you should use `check_header()` which will include the header and
+compile-time. For such cases, you should use `check_header()` which
-run a full compile.
+will include the header and run a full compile.
 
-Note that `has_header()` is much faster than `check_header()`, so it should be
+Note that `has_header()` is much faster than `check_header()`, so it
-used whenever possible.
+should be used whenever possible.
 
 ## New action `copy:` for `configure_file()`
 
 In addition to the existing actions `configuration:` and `command:`,
-[`configure_file()`](Reference-manual.md#configure_file) now accepts a keyword
+[`configure_file()`](Reference-manual.md#configure_file) now accepts a
-argument `copy:` which specifies a new action to copy the file specified with
+keyword argument `copy:` which specifies a new action to copy the file
-the `input:` keyword argument to a file in the build directory with the name
+specified with the `input:` keyword argument to a file in the build
-specified with the `output:` keyword argument.
+directory with the name specified with the `output:` keyword argument.
 
-These three keyword arguments are, as before, mutually exclusive. You can only
+These three keyword arguments are, as before, mutually exclusive. You
-do one action at a time.
+can only do one action at a time.
 
 ## New keyword argument `encoding:` for `configure_file()`
 
-Add a new keyword to [`configure_file()`](Reference-manual.md#configure_file)
+Add a new keyword to
-that allows the developer to specify the input and output file encoding. The
+[`configure_file()`](Reference-manual.md#configure_file) that allows
+the developer to specify the input and output file encoding. The
 default value is the same as before: UTF-8.
 
-In the past, Meson would not handle non-UTF-8/ASCII files correctly, and in the
+In the past, Meson would not handle non-UTF-8/ASCII files correctly,
-worst case would try to coerce it to UTF-8 and mangle the data. UTF-8 is the
+and in the worst case would try to coerce it to UTF-8 and mangle the
-standard encoding now, but sometimes it is necessary to process files that use
+data. UTF-8 is the standard encoding now, but sometimes it is
-a different encoding.
+necessary to process files that use a different encoding.
 
 For additional details see [#3135](https://github.com/mesonbuild/meson/pull/3135).
 
 ## New keyword argument `output_format:` for `configure_file()`
 
-When called without an input file, `configure_file` generates a
+When called without an input file, `configure_file` generates a C
-C header file by default. A keyword argument was added to allow
+header file by default. A keyword argument was added to allow
 specifying the output format, for example for use with nasm or yasm:
 
 ```meson
@@ -121,23 +125,24 @@ and `@PLAINNAME@` substitutions.
 
 ## Deprecated `build_always:` for custom targets
 
-Setting `build_always` to `true` for a custom target not only marks the target
+Setting `build_always` to `true` for a custom target not only marks
-to be always considered out of date, but also adds it to the set of default
+the target to be always considered out of date, but also adds it to
-targets. This option is therefore deprecated and the new option
+the set of default targets. This option is therefore deprecated and
-`build_always_stale` is introduced.
+the new option `build_always_stale` is introduced.
 
-`build_always_stale` *only* marks the target to be always considered out of
+`build_always_stale` *only* marks the target to be always considered
-date, but does not add it to the set of default targets. The old behaviour can
+out of date, but does not add it to the set of default targets. The
-be achieved by combining `build_always_stale` with `build_by_default`.
+old behaviour can be achieved by combining `build_always_stale` with
+`build_by_default`.
 
 The documentation has been updated accordingly.
 
 ## New built-in object type: dictionary
 
-Meson dictionaries use a syntax similar to python's dictionaries,
+Meson dictionaries use a syntax similar to python's dictionaries, but
-but have a narrower scope: they are immutable, keys can only
+have a narrower scope: they are immutable, keys can only be string
-be string literals, and initializing a dictionary with duplicate
+literals, and initializing a dictionary with duplicate keys causes a
-keys causes a fatal error.
+fatal error.
 
 Example usage:
 
@@ -154,15 +159,16 @@ endforeach
 
 ## Array options treat `-Dopt=` and `-Dopt=[]` as equivalent
 
-Prior to this change passing -Dopt= to an array opt would be interpreted as
+Prior to this change passing -Dopt= to an array opt would be
-`['']` (an array with an empty string), now `-Dopt=` is the same as `-Dopt=[]`, an
+interpreted as `['']` (an array with an empty string), now `-Dopt=` is
-empty list.
+the same as `-Dopt=[]`, an empty list.
 
 ## Feature detection based on `meson_version:` in `project()`
 
-Meson will now print a `WARNING:` message during configuration if you use
+Meson will now print a `WARNING:` message during configuration if you
-a function or a keyword argument that was added in a meson version that's newer
+use a function or a keyword argument that was added in a meson version
-than the version specified inside `project()`. For example:
+that's newer than the version specified inside `project()`. For
+example:
 
 ```meson
 project('featurenew', meson_version: '>=0.43')
@@ -193,23 +199,24 @@ WARNING: Project specifies a minimum meson_version '>=0.43' which conflicts with
 
 ## New type of build option for features
 
-A new type of [option called `feature`](Build-options.md#features) can be
+A new type of [option called `feature`](Build-options.md#features) can
-defined in `meson_options.txt` for the traditional `enabled / disabled / auto`
+be defined in `meson_options.txt` for the traditional `enabled /
-tristate. The value of this option can be passed to the `required` keyword
+disabled / auto` tristate. The value of this option can be passed to
-argument of functions `dependency()`, `find_library()`, `find_program()` and
+the `required` keyword argument of functions `dependency()`,
-`add_languages()`.
+`find_library()`, `find_program()` and `add_languages()`.
 
-A new global option `auto_features` has been added to override the value of all
+A new global option `auto_features` has been added to override the
-`auto` features. It is intended to be used by packagers to have full control on
+value of all `auto` features. It is intended to be used by packagers
-which feature must be enabled or disabled.
+to have full control on which feature must be enabled or disabled.
 
 ## New options to `gnome.gdbus_codegen()`
 
-You can now pass additional arguments to gdbus-codegen using the `extra_args`
+You can now pass additional arguments to gdbus-codegen using the
-keyword. This is the same for the other gnome function calls.
+`extra_args` keyword. This is the same for the other gnome function
+calls.
 
-Meson now automatically adds autocleanup support to the generated code. This
+Meson now automatically adds autocleanup support to the generated
-can be modified by setting the autocleanup keyword.
+code. This can be modified by setting the autocleanup keyword.
 
 For example:
 
@@ -235,18 +242,20 @@ $ meson install --only-changed
 
 ## `install_mode:` keyword argument extended to all installable targets
 
-It is now possible to pass an `install_mode` argument to all installable targets,
+It is now possible to pass an `install_mode` argument to all
-such as `executable()`, libraries, headers, man pages and custom/generated
+installable targets, such as `executable()`, libraries, headers, man
-targets.
+pages and custom/generated targets.
 
-The `install_mode` argument can be used to specify the file mode in symbolic
+The `install_mode` argument can be used to specify the file mode in
-format and optionally the owner/uid and group/gid for the installed files.
+symbolic format and optionally the owner/uid and group/gid for the
+installed files.
 
 ## New built-in option `install_umask` with a default value 022
 
-This umask is used to define the default permissions of files and directories
+This umask is used to define the default permissions of files and
-created in the install tree. Files will preserve their executable mode, but the
+directories created in the install tree. Files will preserve their
-exact permissions will obey the `install_umask`.
+executable mode, but the exact permissions will obey the
+`install_umask`.
 
 The `install_umask` can be overridden in the meson command-line:
 
@@ -261,8 +270,8 @@ project('myproject', 'c',
   default_options : ['install_umask=027'])
 ```
 
-To disable the `install_umask`, set it to `preserve`, in which case permissions
+To disable the `install_umask`, set it to `preserve`, in which case
-are copied from the files in their origin.
+permissions are copied from the files in their origin.
 
 ## Octal and binary string literals
 
@@ -275,27 +284,29 @@ int_1365 = 0b10101010101
 
 ## New keyword arguments: 'check' and 'capture' for `run_command()`
 
-If `check:` is `true`, then the configuration will fail if the command returns a
+If `check:` is `true`, then the configuration will fail if the command
-non-zero exit status. The default value is `false` for compatibility reasons.
+returns a non-zero exit status. The default value is `false` for
+compatibility reasons.
 
-`run_command()` used to always capture the output and stored it for use in
+`run_command()` used to always capture the output and stored it for
-build files. However, sometimes the stdout is in a binary format which is meant
+use in build files. However, sometimes the stdout is in a binary
-to be discarded. For that case, you can now set the `capture:` keyword argument
+format which is meant to be discarded. For that case, you can now set
-to `false`.
+the `capture:` keyword argument to `false`.
 
 ## Windows resource files dependencies
 
 The `compile_resources()` function of the `windows` module now takes
 the `depend_files:` and `depends:` keywords.
 
-When using binutils's `windres`, dependencies on files `#include`'d by the
+When using binutils's `windres`, dependencies on files `#include`'d by
-preprocessor are now automatically tracked.
+the preprocessor are now automatically tracked.
 
 ## Polkit support for privileged installation
 
-When running `install`, if installation fails with a permission error and
+When running `install`, if installation fails with a permission error
-`pkexec` is available, Meson will attempt to use it to spawn a permission
+and `pkexec` is available, Meson will attempt to use it to spawn a
-dialog for privileged installation and retry the installation.
+permission dialog for privileged installation and retry the
+installation.
 
-If `pkexec` is not available, the old behaviour is retained and you will need
+If `pkexec` is not available, the old behaviour is retained and you
-to explicitly run the install step with `sudo`.
+will need to explicitly run the install step with `sudo`.

docs/markdown/Release-notes-for-0.48.0.md

@@ -12,8 +12,8 @@ use, such as *debug* and *minsize*. There is also a *plain* type that
 adds nothing by default but instead makes it the user's responsibility
 to add everything by hand. This works but is a bit tedious.
 
-In this release we have added new new options to manually toggle
+In this release we have added new new options to manually toggle e.g.
-e.g. optimization levels and debug info so those can be changed
+optimization levels and debug info so those can be changed
 independently of other options. For example by default the debug
 buildtype has no optmization enabled at all. If you wish to use GCC's
 `-Og` instead, you could set it with the following command:
@@ -29,9 +29,11 @@ manually changed with the new base option `b_vscrt`.
 
 ## Meson warns if two calls to `configure_file()` write to the same file
 
-If two calls to [`configure_file()`](Reference-manual.md#configure_file)
+If two calls to
-write to the same file Meson will print a `WARNING:` message during
+[`configure_file()`](Reference-manual.md#configure_file) write to the
-configuration. For example:
+same file Meson will print a `WARNING:` message during configuration.
+For example:
+
 ```meson
 project('configure_file', 'cpp')
 
@@ -82,18 +84,18 @@ not receive any feedback about what the program is doing.
 
 ## `dependency(version:)` now applies to all dependency types
 
-Previously, version constraints were only enforced for dependencies found using
+Previously, version constraints were only enforced for dependencies
-the pkg-config dependency provider.  These constraints now apply to dependencies
+found using the pkg-config dependency provider. These constraints now
-found using any dependency provider.
+apply to dependencies found using any dependency provider.
 
-Some combinations of dependency, host and method do not currently support
+Some combinations of dependency, host and method do not currently
-discovery of the version.  In these cases, the dependency will not be found if a
+support discovery of the version. In these cases, the dependency will
-version constraint is applied, otherwise the `version()` method for the
+not be found if a version constraint is applied, otherwise the
-dependency object will return `'unknown'`.
+`version()` method for the dependency object will return `'unknown'`.
 
-(If discovering the version in one of these combinations is important to you,
+(If discovering the version in one of these combinations is important
-and a method exists to determine the version in that case, please file an issue
+to you, and a method exists to determine the version in that case,
-with as much information as possible.)
+please file an issue with as much information as possible.)
 
 ## python3 module is deprecated
 
@@ -139,17 +141,17 @@ meson.add_dist_script('dist_cleanup.py')
 
 ## Fatal warnings
 
-A new command line option has been added: `--fatal-meson-warnings`. When enabled, any
+A new command line option has been added: `--fatal-meson-warnings`.
-warning message printed by Meson will be fatal and raise an exception. It is
+When enabled, any warning message printed by Meson will be fatal and
-intended to be used by developers and CIs to easily catch deprecation warnings,
+raise an exception. It is intended to be used by developers and CIs to
-or any other potential issues.
+easily catch deprecation warnings, or any other potential issues.
 
 ## Helper methods added for checking GNU style attributes: `__attribute__(...)`
 
-A set of new helpers have been added to the C and C++ compiler objects for
+A set of new helpers have been added to the C and C++ compiler objects
-checking GNU style function attributes. These are not just simpler to use, they
+for checking GNU style function attributes. These are not just simpler
-may be optimized to return fast on compilers that don't support these
+to use, they may be optimized to return fast on compilers that don't
-attributes. Currently this is true for MSVC.
+support these attributes. Currently this is true for MSVC.
 
 ```meson
 cc = meson.get_compiler('c')
@@ -176,11 +178,12 @@ endforeach
 
 ## `gnome.generate_gir()` now optionally accepts multiple libraries
 
-The GNOME module can now generate a single gir for multiple libraries, which
+The GNOME module can now generate a single gir for multiple libraries,
-is something `g-ir-scanner` supported, but had not been exposed yet.
+which is something `g-ir-scanner` supported, but had not been exposed
+yet.
 
-gnome.generate_gir() will now accept multiple positional arguments, if none
+gnome.generate_gir() will now accept multiple positional arguments, if
-of these arguments are an `Executable` instance.
+none of these arguments are an `Executable` instance.
 
 ## Hotdoc module
 
@@ -242,12 +245,13 @@ add_project_arguments(..., native : true)
 add_project_arguments(..., native : false)
 ```
 
-Also remember that cross compilation is a property of each
+Also remember that cross compilation is a property of each target.
-target. There can be target that are compiled with the native compiler
+There can be target that are compiled with the native compiler and
-and some which are compiled with the cross compiler.
+some which are compiled with the cross compiler.
 
 Unfortunately this change is backwards incompatible and may cause some
-projects to fail building. However this should be very rare in practice.
+projects to fail building. However this should be very rare in
+practice.
 
 ## More flexible `override_find_program()`.
 
@@ -264,25 +268,28 @@ Now, by default `shared_library()` sets `-compatibility_version` and
 `-current_version` of a macOS dylib using the `soversion`.
 
 This can be overridden by using the `darwin_versions:` kwarg to
-[`shared_library()`](Reference-manual.md#shared_library). As usual, you can
+[`shared_library()`](Reference-manual.md#shared_library). As usual,
-also pass this kwarg to `library()` or `build_target()` and it will be used in
+you can also pass this kwarg to `library()` or `build_target()` and it
-the appropriate circumstances.
+will be used in the appropriate circumstances.
 
 ## Version comparison
 
-`dependency(version:)` and other version constraints now handle versions
+`dependency(version:)` and other version constraints now handle
-containing non-numeric characters better, comparing versions using the rpmvercmp
+versions containing non-numeric characters better, comparing versions
-algorithm (as using the `pkg-config` autoconf macro `PKG_CHECK_MODULES` does).
+using the rpmvercmp algorithm (as using the `pkg-config` autoconf
+macro `PKG_CHECK_MODULES` does).
 
-This is a breaking change for exact comparison constraints which rely on the
+This is a breaking change for exact comparison constraints which rely
-previous comparison behaviour of extending the compared versions with `'0'`
+on the previous comparison behaviour of extending the compared
-elements, up to the same length of `'.'`-separated elements.
+versions with `'0'` elements, up to the same length of `'.'`-separated
+elements.
 
-For example, a version of `'0.11.0'` would previously match a version constraint
+For example, a version of `'0.11.0'` would previously match a version
-of `'==0.11'`, but no longer does, being instead considered strictly greater.
+constraint of `'==0.11'`, but no longer does, being instead considered
+strictly greater.
 
-Instead, use a version constraint which exactly compares with the precise
+Instead, use a version constraint which exactly compares with the
-version required, e.g. `'==0.11.0'`.
+precise version required, e.g. `'==0.11.0'`.
 
 ## Keyword argument for GNU symbol visibility
 
@@ -308,13 +315,15 @@ clone-recursive=true
 
 ## `subproject()` function now supports the `required:` kwarg
 
-This allows you to declare an optional subproject. You can now call `found()`
+This allows you to declare an optional subproject. You can now call
-on the return value of the `subproject()` call to see if the subproject is
+`found()` on the return value of the `subproject()` call to see if the
-available before calling `get_variable()` to fetch information from it.
+subproject is available before calling `get_variable()` to fetch
+information from it.
 
 ## `dependency()` objects now support the `.name()` method
 
-You can now fetch the name of the dependency that was searched like so:
+You can now fetch the name of the dependency that was searched like
+so:
 
 ```meson
 glib_dep = dependency('glib-2.0')

docs/markdown/Release-notes-for-0.49.0.md

@@ -7,9 +7,10 @@ short-description: Release notes for 0.49
 
 ## Libgcrypt dependency now supports libgcrypt-config
 
-Earlier, `dependency('libgcrypt')` could only detect the library with pkg-config
+Earlier, `dependency('libgcrypt')` could only detect the library with
-files. Now, if pkg-config files are not found, Meson will look for
+pkg-config files. Now, if pkg-config files are not found, Meson will
-`libgcrypt-config` and if it's found, will use that to find the library.
+look for `libgcrypt-config` and if it's found, will use that to find
+the library.
 
 ## New `section` key for the buildoptions introspection
 
@@ -32,7 +33,7 @@ Cross-compilation is now supported for Renesas RX targets with the
 CC-RX compiler.
 
 The environment path should be set properly for the CC-RX compiler
-executables.  The `-cpu` option with the appropriate value should be
+executables. The `-cpu` option with the appropriate value should be
 mentioned in the cross-file as shown in the snippet below.
 
 ```ini
@@ -41,21 +42,20 @@ c_args      = ['-cpu=rx600']
 cpp_args    = ['-cpu=rx600']
 ```
 
-The default extension of the executable output is `.abs`.  Other
+The default extension of the executable output is `.abs`. Other target
-target specific arguments to the compiler and linker will need to be
+specific arguments to the compiler and linker will need to be added
-added explicitly from the
+explicitly from the
 cross-file(`c_args`/`c_link_args`/`cpp_args`/`cpp_link_args`) or some
-other way.  Refer to the CC-RX User's manual for additional compiler
+other way. Refer to the CC-RX User's manual for additional compiler
 and linker options.
 
 ## CMake `find_package` dependency backend
 
-Meson can now use the CMake `find_package` ecosystem to
+Meson can now use the CMake `find_package` ecosystem to detect
-detect dependencies. Both the old-style `<NAME>_LIBRARIES`
+dependencies. Both the old-style `<NAME>_LIBRARIES` variables as well
-variables as well as imported targets are supported. Meson
+as imported targets are supported. Meson can automatically guess the
-can automatically guess the correct CMake target in most
+correct CMake target in most cases but it is also possible to manually
-cases but it is also possible to manually specify a target
+specify a target with the `modules` property.
-with the `modules` property.
 
 ```meson
 # Implicitly uses CMake as a fallback and guesses a target
@@ -70,10 +70,10 @@ no `method` (or `auto`) was provided in the dependency options.
 
 ## New compiler method `get_argument_syntax`
 
-The compiler object now has `get_argument_syntax` method, which returns a
+The compiler object now has `get_argument_syntax` method, which
-string value of `gcc`, `msvc`, or an undefined value string value. This can be
+returns a string value of `gcc`, `msvc`, or an undefined value string
-used to determine if a compiler uses gcc syntax (`-Wfoo`), msvc syntax
+value. This can be used to determine if a compiler uses gcc syntax
-(`/w1234`), or some other kind of arguments.
+(`-Wfoo`), msvc syntax (`/w1234`), or some other kind of arguments.
 
 ```meson
 cc = meson.get_compiler('c')
@@ -93,22 +93,28 @@ endif
 
 ## Return `Disabler()` instead of not-found object
 
-Functions such as `dependency()`, `find_library()`, `find_program()`, and
+Functions such as `dependency()`, `find_library()`, `find_program()`,
-`python.find_installation()` have a new keyword argument: `disabler`. When set
+and `python.find_installation()` have a new keyword argument:
-to `true` those functions return `Disabler()` objects instead of not-found
+`disabler`. When set to `true` those functions return `Disabler()`
-objects.
+objects instead of not-found objects.
 
 ## `introspect --projectinfo` can now be used without configured build directory
 
-This allows IDE integration to get information about the project before the user has configured a build directory.
+This allows IDE integration to get information about the project
+before the user has configured a build directory.
 
-Before you could use `meson.py introspect --projectinfo build-directory`.
+Before you could use `meson.py introspect --projectinfo
-Now you also can use `meson.py introspect --projectinfo project-dir/meson.build`.
+build-directory`. Now you also can use `meson.py introspect
+--projectinfo project-dir/meson.build`.
 
-The output is similar to the output with a build directory but additionally also includes information from `introspect --buildsystem-files`.
+The output is similar to the output with a build directory but
+additionally also includes information from `introspect
+--buildsystem-files`.
+
+For example `meson.py introspect --projectinfo test\ cases/common/47\
+subproject\ options/meson.build` This outputs (pretty printed for
+readability):
 
-For example `meson.py introspect --projectinfo test\ cases/common/47\ subproject\ options/meson.build`
-This outputs (pretty printed for readability):
 ```
 {
     "buildsystem_files": [
@@ -166,28 +172,28 @@ is a hard error.
 
 ## Manpages are no longer compressed implicitly
 
-Earlier, the `install_man` command has automatically compressed installed
+Earlier, the `install_man` command has automatically compressed
-manpages into `.gz` format. This collided with manpage compression hooks
+installed manpages into `.gz` format. This collided with manpage
-already used by various distributions. Now, manpages are installed uncompressed
+compression hooks already used by various distributions. Now, manpages
-and distributors are expected to handle compressing them according to their own
+are installed uncompressed and distributors are expected to handle
-compression preferences.
+compressing them according to their own compression preferences.
 
 ## Native config files
 
-Native files (`--native-file`) are the counterpart to cross files (`--cross-file`),
+Native files (`--native-file`) are the counterpart to cross files
-and allow specifying information about the build machine, both when cross compiling
+(`--cross-file`), and allow specifying information about the build
-and when not.
+machine, both when cross compiling and when not.
 
-Currently the native files only allow specifying the names of binaries, similar
+Currently the native files only allow specifying the names of
-to the cross file, for example:
+binaries, similar to the cross file, for example:
 
 ```ini
 [binaries]
 llvm-config = "/opt/llvm-custom/bin/llvm-config"
 ```
 
-Will override the llvm-config used for *native* binaries. Targets for the host
+Will override the llvm-config used for *native* binaries. Targets for
-machine will continue to use the cross file.
+the host machine will continue to use the cross file.
 
 ## Foreach `break` and `continue`
 
@@ -241,8 +247,8 @@ path elements:
 joined = 'foo' / 'bar'
 ```
 
-Before Meson 0.49, joining path elements was done with the legacy `join_paths`
+Before Meson 0.49, joining path elements was done with the legacy
-function, but the `/` syntax above is now recommended.
+`join_paths` function, but the `/` syntax above is now recommended.
 
 ```meson
 joined = join_paths('foo', 'bar')
@@ -252,29 +258,34 @@ This only works for strings.
 
 ## Position-independent executables
 
-When `b_pie` option, or `executable()`'s `pie` keyword argument is set to
+When `b_pie` option, or `executable()`'s `pie` keyword argument is set
-`true`, position-independent executables are built. All their objects are built
+to `true`, position-independent executables are built. All their
-with `-fPIE` and the executable is linked with `-pie`. Any static library they
+objects are built with `-fPIE` and the executable is linked with
-link must be built with `pic` set to `true` (see `b_staticpic` option).
+`-pie`. Any static library they link must be built with `pic` set to
+`true` (see `b_staticpic` option).
 
 ## Deprecation warning in pkg-config generator
 
-All libraries passed to the `libraries` keyword argument of the `generate()`
+All libraries passed to the `libraries` keyword argument of the
-method used to be associated with that generated pkg-config file. That means
+`generate()` method used to be associated with that generated
-that any subsequent call to `generate()` where those libraries appear would add
+pkg-config file. That means that any subsequent call to `generate()`
-the filebase of the `generate()` that first contained them into `Requires:` or
+where those libraries appear would add the filebase of the
-`Requires.private:` field instead of adding an `-l` to `Libs:` or `Libs.private:`.
+`generate()` that first contained them into `Requires:` or
-
+`Requires.private:` field instead of adding an `-l` to `Libs:` or
-This behaviour is now deprecated. The library that should be associated with
+`Libs.private:`.
-the generated pkg-config file should be passed as first positional argument
+
-instead of in the `libraries` keyword argument. The previous behaviour is
+This behaviour is now deprecated. The library that should be
-maintained but prints a deprecation warning and support for this will be removed
+associated with the generated pkg-config file should be passed as
-in a future Meson release. If you can not create the needed pkg-config file
+first positional argument instead of in the `libraries` keyword
-without this warning, please file an issue with as much details as possible
+argument. The previous behaviour is maintained but prints a
-about the situation.
+deprecation warning and support for this will be removed in a future
-
+Meson release. If you can not create the needed pkg-config file
-For example this sample will write `Requires: liba` into `libb.pc` but print a
+without this warning, please file an issue with as much details as
-deprecation warning:
+possible about the situation.
+
+For example this sample will write `Requires: liba` into `libb.pc` but
+print a deprecation warning:
+
 ```meson
 liba = library(...)
 pkg.generate(libraries : liba)

docs/markdown/Release-notes-for-0.50.0.md

@@ -7,19 +7,20 @@ short-description: Release notes for 0.50.0
 
 ## Added `cmake_module_path` and `cmake_args` to dependency
 
-The CMake dependency backend can now make use of existing `Find<name>.cmake`
+The CMake dependency backend can now make use of existing
-files by setting the `CMAKE_MODULE_PATH` with the new `dependency()` property
+`Find<name>.cmake` files by setting the `CMAKE_MODULE_PATH` with the
-`cmake_module_path`. The paths given to `cmake_module_path` should be relative
+new `dependency()` property `cmake_module_path`. The paths given to
-to the project source directory.
+`cmake_module_path` should be relative to the project source
+directory.
 
-Furthermore the property `cmake_args` was added to give CMake additional
+Furthermore the property `cmake_args` was added to give CMake
-parameters.
+additional parameters.
 
 ## Added PGI compiler support
 
 Nvidia / PGI C, C++ and Fortran
 [no-cost](https://www.pgroup.com/products/community.htm) compilers are
-now supported.  They have been tested on Linux so far.
+now supported. They have been tested on Linux so far.
 
 
 
@@ -65,8 +66,10 @@ not.
 
 ## Fix ninja console log from generators with multiple output nodes
 
-This resolves [issue #4760](https://github.com/mesonbuild/meson/issues/4760)
+This resolves [issue
-where a generator with multiple output nodes printed an empty string to the console
+#4760](https://github.com/mesonbuild/meson/issues/4760) where a
+generator with multiple output nodes printed an empty string to the
+console
 
 ## `introspect --buildoptions` can now be used without configured build directory
 
@@ -100,11 +103,11 @@ executable(..., include_directories: foo_inc)
 
 ## Fortran submodule support
 
-Initial support for Fortran `submodule` was added, where the submodule is in
+Initial support for Fortran `submodule` was added, where the submodule
-the same or different file than the parent `module`.
+is in the same or different file than the parent `module`. The
-The submodule hierarchy specified in the source Fortran code `submodule`
+submodule hierarchy specified in the source Fortran code `submodule`
-statements are used by Meson to resolve source file dependencies.
+statements are used by Meson to resolve source file dependencies. For
-For example:
+example:
 
 ```fortran
 submodule (ancestor:parent) child
@@ -113,13 +116,14 @@ submodule (ancestor:parent) child
 
 ## Add `subproject_dir` to `--projectinfo` introspection output
 
-This allows applications interfacing with Meson (such as IDEs) to know about
+This allows applications interfacing with Meson (such as IDEs) to know
-an overridden subproject directory.
+about an overridden subproject directory.
 
 ## Find library with its headers
 
-The `find_library()` method can now also verify if the library's headers are
+The `find_library()` method can now also verify if the library's
-found in a single call, using the `has_header()` method internally.
+headers are found in a single call, using the `has_header()` method
+internally.
 
 ```meson
 # Aborts if the 'z' library is found but not its header file
@@ -128,8 +132,9 @@ zlib = find_library('z', has_headers : 'zlib.h')
 zlib = find_library('z', has_headers : 'zlib.h', required : false)
 ```
 
-Any keyword argument with the `header_` prefix passed to `find_library()` will
+Any keyword argument with the `header_` prefix passed to
-be passed to the `has_header()` method with the prefix removed.
+`find_library()` will be passed to the `has_header()` method with the
+prefix removed.
 
 ```meson
 libfoo = find_library('foo',
@@ -214,9 +219,9 @@ what to extract. Previously, file paths could only be passed as strings.
 
 ## Changed the JSON format of the introspection
 
-All paths used in the meson introspection JSON format are now absolute. This
+All paths used in the meson introspection JSON format are now
-affects the `filename` key in the targets introspection and the output of
+absolute. This affects the `filename` key in the targets introspection
-`--buildsystem-files`.
+and the output of `--buildsystem-files`.
 
 Furthermore, the `filename` and `install_filename` keys in the targets
 introspection are now lists of strings with identical length.
@@ -262,21 +267,22 @@ The output format is as follows:
 ]
 ```
 
-The `required` keyword specifies whether the dependency is marked as required
+The `required` keyword specifies whether the dependency is marked as
-in the `meson.build` (all dependencies are required by default). The
+required in the `meson.build` (all dependencies are required by
-`conditional` key indicates whether the `dependency()` function was called
+default). The `conditional` key indicates whether the `dependency()`
-inside a conditional block. In a real meson run these dependencies might not be
+function was called inside a conditional block. In a real meson run
-used, thus they _may_ not be required, even if the `required` key is set. The
+these dependencies might not be used, thus they _may_ not be required,
-`has_fallback` key just indicates whether a fallback was directly set in the
+even if the `required` key is set. The `has_fallback` key just
-`dependency()` function.
+indicates whether a fallback was directly set in the `dependency()`
+function.
 
 ## `introspect --targets` can now be used without configured build directory
 
-It is now possible to run `meson introspect --targets /path/to/meson.build`
+It is now possible to run `meson introspect --targets
-without a configured build directory.
+/path/to/meson.build` without a configured build directory.
 
-The generated output is similar to running the introspection with a build
+The generated output is similar to running the introspection with a
-directory. However, there are some key differences:
+build directory. However, there are some key differences:
 
 - The paths in `filename` now are _relative_ to the future build directory
 - The `install_filename` key is completely missing
@@ -285,26 +291,27 @@ directory. However, there are some key differences:
   - Empty lists for `compiler` and `parameters` and `generated_sources`
   - The `sources` list _should_ contain all sources of the target
 
-There is no guarantee that the sources list in `target_sources` is correct.
+There is no guarantee that the sources list in `target_sources` is
-There might be differences, due to internal limitations. It is also not
+correct. There might be differences, due to internal limitations. It
-guaranteed that all targets will be listed in the output. It might even be
+is also not guaranteed that all targets will be listed in the output.
-possible that targets are listed, which won't exist when meson is run normally.
+It might even be possible that targets are listed, which won't exist
-This can happen if a target is defined inside an if statement.
+when meson is run normally. This can happen if a target is defined
-Use this feature with care.
+inside an if statement. Use this feature with care.
 
 ## Added option to introspect multiple parameters at once
 
 Meson introspect can now print the results of multiple introspection
-commands in a single call. The results are then printed as a single JSON
+commands in a single call. The results are then printed as a single
-object.
+JSON object.
 
 The format for a single command was not changed to keep backward
 compatibility.
 
-Furthermore the option `-a,--all`, `-i,--indent` and `-f,--force-object-output`
+Furthermore the option `-a,--all`, `-i,--indent` and
-were added to print all introspection information in one go, format the
+`-f,--force-object-output` were added to print all introspection
-JSON output (the default is still compact JSON) and force use the new
+information in one go, format the JSON output (the default is still
-output format, even if only one introspection command was given.
+compact JSON) and force use the new output format, even if only one
+introspection command was given.
 
 A complete introspection dump is also stored in the `meson-info`
 directory. This dump will be (re)generated each time meson updates the
@@ -319,10 +326,10 @@ Additionlly the format of `meson introspect target` was changed:
 
 ## `meson configure` can now print the default options of an unconfigured project
 
-With this release, it is also possible to get a list of all build options
+With this release, it is also possible to get a list of all build
-by invoking `meson configure` with the project source directory or
+options by invoking `meson configure` with the project source
-the path to the root `meson.build`. In this case, meson will print the
+directory or the path to the root `meson.build`. In this case, meson
-default values of all options.
+will print the default values of all options.
 
 ## HDF5
 
@@ -330,13 +337,14 @@ HDF5 support is added via pkg-config.
 
 ## Added the `meson-info.json` introspection file
 
-Meson now generates a `meson-info.json` file in the `meson-info` directory
+Meson now generates a `meson-info.json` file in the `meson-info`
-to provide introspection information about the latest meson run. This file
+directory to provide introspection information about the latest meson
-is updated when the build configuration is changed and the build files are
+run. This file is updated when the build configuration is changed and
-(re)generated.
+the build files are (re)generated.
 
 ## New kwarg `install:` for `configure_file()`
 
-Previously when using `configure_file()`, you could install the outputted file
+Previously when using `configure_file()`, you could install the
-by setting the `install_dir:` keyword argument. Now, there is an explicit kwarg
+outputted file by setting the `install_dir:` keyword argument. Now,
-`install:` to enable/disable it. Omitting it will maintain the old behaviour.
+there is an explicit kwarg `install:` to enable/disable it. Omitting
+it will maintain the old behaviour.

docs/markdown/Release-notes-for-0.51.0.md

@@ -8,38 +8,41 @@ short-description: Release notes for 0.51.0
 ## (C) Preprocessor flag handling
 
 Meson previously stored `CPPFLAGS` and per-language compilation flags
-separately. (That latter would come from `CFLAGS`, `CXXFLAGS`, etc., along with
+separately. (That latter would come from `CFLAGS`, `CXXFLAGS`, etc.,
-`<lang>_args` options whether specified no the command-line interface (`-D..`),
+along with `<lang>_args` options whether specified no the command-line
-`meson.build` (`default_options`), or cross file (`[properties]`).) This was
+interface (`-D..`), `meson.build` (`default_options`), or cross file
-mostly unobservable, except for certain preprocessor-only checks like
+(`[properties]`).) This was mostly unobservable, except for certain
-`check_header` would only use the preprocessor flags, leading to confusion if
+preprocessor-only checks like `check_header` would only use the
-some `-isystem` was in `CFLAGS` but not `CPPFLAGS`. Now, they are lumped
+preprocessor flags, leading to confusion if some `-isystem` was in
-together, and `CPPFLAGS`, for the languages which are deemed to care to about,
+`CFLAGS` but not `CPPFLAGS`. Now, they are lumped together, and
-is just another source of compilation flags along with the others already
+`CPPFLAGS`, for the languages which are deemed to care to about, is
+just another source of compilation flags along with the others already
 listed.
 
 ## Sanity checking compilers with user flags
 
-Sanity checks previously only used user-specified flags for cross compilers, but
+Sanity checks previously only used user-specified flags for cross
-now do in all cases.
+compilers, but now do in all cases.
 
-All compilers meson might decide to use for the build are "sanity checked"
+All compilers meson might decide to use for the build are "sanity
-before other tests are run. This usually involves building simple executable and
+checked" before other tests are run. This usually involves building
-trying to run it. Previously user flags (compilation and/or linking flags) were
+simple executable and trying to run it. Previously user flags
-used for sanity checking cross compilers, but not native compilers.  This is
+(compilation and/or linking flags) were used for sanity checking cross
-because such flags might be essential for a cross binary to succeed, but usually
+compilers, but not native compilers. This is because such flags might
-aren't for a native compiler.
+be essential for a cross binary to succeed, but usually aren't for a
+native compiler.
 
-In recent releases, there has been an effort to minimize the special-casing of
+In recent releases, there has been an effort to minimize the
-cross or native builds so as to make building more predictable in less-tested
+special-casing of cross or native builds so as to make building more
-cases. Since this the user flags are necessary for cross, but not harmful for
+predictable in less-tested cases. Since this the user flags are
-native, it makes more sense to use them in all sanity checks than use them in no
+necessary for cross, but not harmful for native, it makes more sense
-sanity checks, so this is what we now do.
+to use them in all sanity checks than use them in no sanity checks, so
+this is what we now do.
 
 ## New `sourceset` module
 
 A new module, `sourceset`, was added to help building many binaries
-from the same source files.  Source sets associate source files and
+from the same source files. Source sets associate source files and
 dependencies to keys in a `configuration_data` object or a dictionary;
 they then take multiple `configuration_data` objects or dictionaries,
 and compute the set of source files and dependencies for each of those
@@ -69,9 +72,10 @@ shared_module(...)
 
 ## New modules kwarg for python.find_installation
 
-This mirrors the modules argument that some kinds of dependencies (such as
+This mirrors the modules argument that some kinds of dependencies
-qt, llvm, and cmake based dependencies) take, allowing you to check that a
+(such as qt, llvm, and cmake based dependencies) take, allowing you to
-particular module is available when getting a python version.
+check that a particular module is available when getting a python
+version.
 
 ```meson
 py = import('python').find_installation('python3', modules : ['numpy'])
@@ -79,10 +83,10 @@ py = import('python').find_installation('python3', modules : ['numpy'])
 
 ## Support for the Intel Compiler on Windows (ICL)
 
-Support has been added for ICL.EXE and ifort on windows. The support should be
+Support has been added for ICL.EXE and ifort on windows. The support
-on part with ICC support on Linux/MacOS. The ICL C/C++ compiler behaves like
+should be on part with ICC support on Linux/MacOS. The ICL C/C++
-Microsoft's CL.EXE rather than GCC/Clang like ICC does, and has a different id,
+compiler behaves like Microsoft's CL.EXE rather than GCC/Clang like
-`intel-cl` to differentiate it.
+ICC does, and has a different id, `intel-cl` to differentiate it.
 
 ```meson
 cc = meson.get_compiler('c')
@@ -93,8 +97,8 @@ endif
 
 ## Added basic support for the Xtensa CPU toolchain
 
-You can now use `xt-xcc`, `xt-xc++`, `xt-nm`, etc... on your cross compilation
+You can now use `xt-xcc`, `xt-xc++`, `xt-nm`, etc... on your cross
-file and meson won't complain about an unknown toolchain.
+compilation file and meson won't complain about an unknown toolchain.
 
 
 ## Dependency objects now have a get_variable method
@@ -118,11 +122,13 @@ endif
 ## CMake prefix path overrides
 
 When using pkg-config as a dependency resolver we can pass
-`-Dpkg_config_path=$somepath` to extend or overwrite where pkg-config will
+`-Dpkg_config_path=$somepath` to extend or overwrite where pkg-config
-search for dependencies. Now cmake can do the same, as long as the dependency
+will search for dependencies. Now cmake can do the same, as long as
-uses a ${Name}Config.cmake file (not a Find{$Name}.cmake file), by passing
+the dependency uses a ${Name}Config.cmake file (not a
-`-Dcmake_prefix_path=list,of,paths`. It is important that point this at the
+Find{$Name}.cmake file), by passing
-prefix that the dependency is installed into, not the cmake path.
+`-Dcmake_prefix_path=list,of,paths`. It is important that point this
+at the prefix that the dependency is installed into, not the cmake
+path.
 
 If you have installed something to `/tmp/dep`, which has a layout like:
 ```
@@ -162,7 +168,7 @@ executable(..., link_language : 'fortran')
 ```
 
 A specific case this option fixes is where for example the main
-program is Fortran that calls C and/or C++ code.  The automatic
+program is Fortran that calls C and/or C++ code. The automatic
 language detection of Meson prioritizes C/C++, and so an compile-time
 error results like `undefined reference to main`, because the linker
 is C or C++ instead of Fortran, which is fixed by this per-target
@@ -176,11 +182,12 @@ kconfig output files from `meson.build`.
 
 ## Add new `meson subprojects foreach` command
 
-`meson subprojects` has learned a new `foreach` command which accepts a command
+`meson subprojects` has learned a new `foreach` command which accepts
-with arguments and executes it in each subproject directory.
+a command with arguments and executes it in each subproject directory.
 
-For example this can be useful to check the status of subprojects (e.g. with
+For example this can be useful to check the status of subprojects
-`git status` or `git diff`) before performing other actions on them.
+(e.g. with `git status` or `git diff`) before performing other actions
+on them.
 
 
 ## Added c17 and c18 as c_std values for recent GCC and Clang Versions
@@ -243,18 +250,19 @@ cg = generator(program_runner,
 ## Specifying options per mer machine
 
 Previously, no cross builds were controllable from the command line.
-Machine-specific options like the pkg-config path and compiler options only
+Machine-specific options like the pkg-config path and compiler options
-affected native targets, that is to say all targets in native builds, and
+only affected native targets, that is to say all targets in native
-`native: true` targets in cross builds. Now, prefix the option with `build.` to
+builds, and `native: true` targets in cross builds. Now, prefix the
-affect build machine targets, and leave it unprefixed to affect host machine
+option with `build.` to affect build machine targets, and leave it
-targets.
+unprefixed to affect host machine targets.
 
-For those trying to ensure native and cross builds to the same platform produced
+For those trying to ensure native and cross builds to the same
-the same result, the old way was frustrating because very different invocations
+platform produced the same result, the old way was frustrating because
-were needed to affect the same targets, if it was possible at all. Now, the same
+very different invocations were needed to affect the same targets, if
-command line arguments affect the same targets everywhere --- Meson is closer to
+it was possible at all. Now, the same command line arguments affect
-ignoring whether the "overall" build is native or cross, and just caring about
+the same targets everywhere --- Meson is closer to ignoring whether
-whether individual targets are for the build or host machines.
+the "overall" build is native or cross, and just caring about whether
+individual targets are for the build or host machines.
 
 
 ## subproject.get_variable() now accepts a `fallback` argument
@@ -269,26 +277,27 @@ var = subproject.get_variable('does-not-exist', 'fallback-value')
 
 ## Add keyword `static` to `find_library`
 
-`find_library` has learned the `static` keyword. They keyword must be a boolean,
+`find_library` has learned the `static` keyword. They keyword must be
-where `true` only searches for static libraries and `false` only searches for
+a boolean, where `true` only searches for static libraries and `false`
-dynamic/shared. Leaving the keyword unset will keep the old behavior of first
+only searches for dynamic/shared. Leaving the keyword unset will keep
-searching for dynamic and then falling back to static.
+the old behavior of first searching for dynamic and then falling back
+to static.
 
 ## Fortran `include` statements recursively parsed
 
 While non-standard and generally not recommended, some legacy Fortran
-programs use `include` directives to inject code inline.  Since v0.51,
+programs use `include` directives to inject code inline. Since v0.51,
 Meson can handle Fortran `include` directives recursively.
 
 DO NOT list `include` files as sources for a target, as in general
-their syntax is not correct as a standalone target.  In general
+their syntax is not correct as a standalone target. In general
 `include` files are meant to be injected inline as if they were copy
 and pasted into the source file.
 
 `include` was never standard and was superceded by Fortran 90 `module`.
 
 The `include` file is only recognized by Meson if it has a Fortran
-file suffix, such as `.f` `.F` `.f90` `.F90` or similar.  This is to
+file suffix, such as `.f` `.F` `.f90` `.F90` or similar. This is to
 avoid deeply nested scanning of large external legacy C libraries that
 only interface to Fortran by `include biglib.h` or similar.
 
@@ -326,4 +335,3 @@ subprojects in question.
 ## Multiple cross files can be specified
 
 `--cross-file` can be passed multiple times, with the configuration files overlaying the same way as `--native-file`.
-

docs/markdown/Release-notes-for-0.52.0.md

@@ -28,18 +28,19 @@ now give a dictionary.
 runtarget alias_target(target_name, dep1, ...)
 ```
 
-This function creates a new top-level target. Like all top-level targets, this
+This function creates a new top-level target. Like all top-level
-integrates with the selected backend. For instance, with Ninja you can
+targets, this integrates with the selected backend. For instance, with
-run it as `ninja target_name`. This is a dummy target that does not execute any
+Ninja you can run it as `ninja target_name`. This is a dummy target
-command, but ensures that all dependencies are built. Dependencies can be any
+that does not execute any command, but ensures that all dependencies
-build target (e.g. return value of executable(), custom_target(), etc)
+are built. Dependencies can be any build target (e.g. return value of
+executable(), custom_target(), etc)
 
 
 ## Enhancements to the pkg_config_path argument
 
-Setting sys_root in the [properties] section of your cross file will now set
+Setting sys_root in the [properties] section of your cross file will
-PKG_CONFIG_SYSROOT_DIR automatically for host system dependencies when
+now set PKG_CONFIG_SYSROOT_DIR automatically for host system
-cross compiling.
+dependencies when cross compiling.
 
 ## The meson test program now accepts an additional "--gdb-path" argument to specify the GDB binary
 
@@ -53,13 +54,14 @@ $ meson test --gdb --gdb-path cgdb testname
 
 ## Better support for illumos and Solaris
 
-illumos (and hopefully Solaris) support has been dramatically improved, and one
+illumos (and hopefully Solaris) support has been dramatically
-can reasonably expect projects to compile.
+improved, and one can reasonably expect projects to compile.
 
 ## Splitting of Compiler.get_function_attribute('visibility')
 
-On macOS there is no `protected` visibility, which results in the visbility
+On macOS there is no `protected` visibility, which results in the
-check always failing. 0.52.0 introduces two changes to improve this situation:
+visbility check always failing. 0.52.0 introduces two changes to
+improve this situation:
 
 1. the "visibility" check no longer includes "protected"
 2. a new set of "split" checks are introduced which check for a single
@@ -86,9 +88,9 @@ Add `dependency('blocks')` to use the Clang blocks extension.
 
 ## Meson's builtin b_lundef is now supported on macOS
 
-This has always been possible, but there are some additional restrictions on
+This has always been possible, but there are some additional
-macOS (mainly do to Apple only features). With the linker internal
+restrictions on macOS (mainly do to Apple only features). With the
-re-architecture this has become possible
+linker internal re-architecture this has become possible
 
 ## Compiler and dynamic linker representation split
 
@@ -119,7 +121,8 @@ python run_project_tests.py --only fortran
 python run_project_tests.py --only fortran python3
 ```
 
-This assists Meson development by only running the tests for the portion of Meson being worked on during local development.
+This assists Meson development by only running the tests for the
+portion of Meson being worked on during local development.
 
 ## Experimental Webassembly support via Emscripten
 
@@ -129,13 +132,14 @@ subject to change.
 
 ## Version check in `find_program()`
 
-A new `version` keyword argument has been added to `find_program` to specify
+A new `version` keyword argument has been added to `find_program` to
-the required version. See [`dependency()`](#dependency) for argument format.
+specify the required version. See [`dependency()`](#dependency) for
-The version of the program is determined by running `program_name --version`
+argument format. The version of the program is determined by running
-command. If stdout is empty it fallbacks to stderr. If the output contains more
+`program_name --version` command. If stdout is empty it fallbacks to
-text than simply a version number, only the first occurrence of numbers separated
+stderr. If the output contains more text than simply a version number,
-by dots is kept. If the output is more complicated than that, the version
+only the first occurrence of numbers separated by dots is kept. If the
-checking will have to be done manually using [`run_command()`](#run_command).
+output is more complicated than that, the version checking will have
+to be done manually using [`run_command()`](#run_command).
 
 ## Added `vs_module_defs` to `shared_module()`
 
@@ -144,9 +148,9 @@ Like `shared_library()`, `shared_module()` now accepts
 
 ## Improved support for static libraries
 
-Static libraries had numerous shortcomings in the past, especially when using
+Static libraries had numerous shortcomings in the past, especially
-uninstalled static libraries. This release brings many internal changes in the
+when using uninstalled static libraries. This release brings many
-way they are handled, including:
+internal changes in the way they are handled, including:
 
 - `link_whole:` of static libraries. In the example below, lib2 used to miss
   symbols from lib1 and was unusable.
@@ -172,10 +176,10 @@ lib2 = both_libraries(sources, link_with : lib1, install : true)
 pkg.generate(lib2)
 ```
 
-Many projects have been using `extract_all_objects()` to work around those issues,
+Many projects have been using `extract_all_objects()` to work around
-and hopefully those hacks could now be removed. Since this is a pretty large
+those issues, and hopefully those hacks could now be removed. Since
-change, please double check if your static libraries behave correctly, and
+this is a pretty large change, please double check if your static
-report any regression.
+libraries behave correctly, and report any regression.
 
 ## Enhancements to the kconfig module
 
@@ -189,9 +193,9 @@ all include directories of the dependency are marked as system dependencies.
 
 The default value of `include_type` is `'preserve'`.
 
-Additionally, it is also possible to check and change the `include_type`
+Additionally, it is also possible to check and change the
-state of an existing dependency object with the new `include_type()` and
+`include_type` state of an existing dependency object with the new
-`as_system()` methods.
+`include_type()` and `as_system()` methods.
 
 ## Enhancements to `configure_file()`
 
@@ -212,10 +216,10 @@ Simplify `native` flag behavior in `add_global_arguments`,
 
  - No native flag is the same as `native: false`
 
-This further simplifies behavior to match the "build vs host" decision done in
+This further simplifies behavior to match the "build vs host" decision
-last release with `c_args` vs `build_c_args`. The underlying motivation in both
+done in last release with `c_args` vs `build_c_args`. The underlying
-cases is to execute the same commands whether the overall build is native or
+motivation in both cases is to execute the same commands whether the
-cross.
+overall build is native or cross.
 
 ## Allow checking if a variable is a disabler
 
@@ -225,15 +229,16 @@ and false otherwise.
 
 ## gtkdoc-check support
 
-`gnome.gtkdoc()` now has a `check` keyword argument. If `true` runs it will run
+`gnome.gtkdoc()` now has a `check` keyword argument. If `true` runs it
-`gtkdoc-check` when running unit tests. Note that this has the downside of
+will run `gtkdoc-check` when running unit tests. Note that this has
-rebuilding the doc for each build, which is often very slow. It usually should
+the downside of rebuilding the doc for each build, which is often very
-be enabled only in CI.
+slow. It usually should be enabled only in CI.
 
 ## `gnome.gtkdoc()` returns target object
 
-`gnome.gtkdoc()` now returns a target object that can be passed as dependency to
+`gnome.gtkdoc()` now returns a target object that can be passed as
-other targets using generated doc files (e.g. in `content_files` of another doc).
+dependency to other targets using generated doc files (e.g. in
+`content_files` of another doc).
 
 ## Dist is now a top level command
 
@@ -245,4 +250,3 @@ determine which kinds of archives to create:
 ```meson
 meson dist --formats=xztar,zip
 ```
-

docs/markdown/Release-notes-for-0.53.0.md

@@ -18,10 +18,11 @@ assert(fs.exists('important_file'),
 
 ## meson dist --include-subprojects
 
-`meson dist` command line now gained `--include-subprojects` command line option.
+`meson dist` command line now gained `--include-subprojects` command
-When enabled, the source tree of all subprojects used by the current build will
+line option. When enabled, the source tree of all subprojects used by
-also be included in the final tarball. This is useful to distribute self contained
+the current build will also be included in the final tarball. This is
-tarball that can be built offline (i.e. `--wrap-mode=nodownload`).
+useful to distribute self contained tarball that can be built offline
+(i.e. `--wrap-mode=nodownload`).
 
 ## Added new Meson templates for `Dlang`, `Rust`, `Objective-C`
 
@@ -31,8 +32,9 @@ Meson now ships with predefined project templates for `Dlang`,
 
 ## Add a new summary() function
 
-A new function [`summary()`](Reference-manual.md#summary) has been added to
+A new function [`summary()`](Reference-manual.md#summary) has been
-summarize build configuration at the end of the build process.
+added to summarize build configuration at the end of the build
+process.
 
 Example:
 ```meson
@@ -69,16 +71,19 @@ My Project 1.0
 
 ## Generic Overrider for Dynamic Linker selection
 
-Previous to meson 0.52.0 you set the dynamic linker using compiler specific
+Previous to meson 0.52.0 you set the dynamic linker using compiler
-flags passed via language flags and hoped things worked out. In meson 0.52.0
+specific flags passed via language flags and hoped things worked out.
-meson started detecting the linker and making intelligent decisions about
+In meson 0.52.0 meson started detecting the linker and making
-using it. Unfortunately this broke choosing a non-default linker.
+intelligent decisions about using it. Unfortunately this broke
+choosing a non-default linker.
 
-Now there is a generic mechanism for doing this. In 0.53.0, you can use the `LD`
+Now there is a generic mechanism for doing this. In 0.53.0, you can
-environment variable. **In 0.53.1** this was changed to `<compiler_variable>_LD`,
+use the `LD` environment variable. **In 0.53.1** this was changed to
-such as `CC_LD`, `CXX_LD`, `D_LD`, etc due to regressions. The usual meson
+`<compiler_variable>_LD`, such as `CC_LD`, `CXX_LD`, `D_LD`, etc due
-[environment variable rules](https://mesonbuild.com/Running-Meson.html#environment-variables)
+to regressions. The usual meson [environment variable
-apply. Alternatively, you can add the following to a cross or native file:
+rules](https://mesonbuild.com/Running-Meson.html#environment-variables)
+apply. Alternatively, you can add the following to a cross or native
+file:
 
 In 0.53.0:
 
@@ -105,10 +110,11 @@ And meson will select the linker if possible.
 
 ## `fortran_std` option
 
-**new in 0.53.0**
+**new in 0.53.0** Akin to the `c_std` and `cpp_std` options, the
-Akin to the `c_std` and `cpp_std` options, the `fortran_std` option sets Fortran compilers to warn or error on non-Fortran standard code.
+`fortran_std` option sets Fortran compilers to warn or error on
-Only the Gfortran and Intel Fortran compilers have support for this option.
+non-Fortran standard code. Only the Gfortran and Intel Fortran
-Other Fortran compilers ignore the `fortran_std` option.
+compilers have support for this option. Other Fortran compilers ignore
+the `fortran_std` option.
 
 Supported values for `fortran_std` include:
 
@@ -120,8 +126,9 @@ Supported values for `fortran_std` include:
 
 ## python.dependency() embed kwarg
 
-Added the `embed` kwarg to the python module dependency function to select
+Added the `embed` kwarg to the python module dependency function to
-the python library that can be used to embed python into an application.
+select the python library that can be used to embed python into an
+application.
 
 ## Scalapack
 
@@ -131,8 +138,9 @@ added in **0.53.0**:
 scalapack = dependency('scalapack')
 ```
 
-Historically and through today, typical Scalapack setups have broken and incomplete pkg-config or
+Historically and through today, typical Scalapack setups have broken
-FindScalapack.cmake. Meson handles finding Scalapack on setups including:
+and incomplete pkg-config or FindScalapack.cmake. Meson handles
+finding Scalapack on setups including:
 
 * Linux: Intel MKL or OpenMPI + Netlib
 * MacOS: Intel MKL or OpenMPI + Netlib
@@ -165,8 +173,8 @@ d += {k : 43}
 
 ## Improved CMake subprojects support
 
-With this release even more CMake projects are supported via
+With this release even more CMake projects are supported via [CMake
-[CMake subprojects](CMake-module.md#cmake-subprojects) due to these internal
+subprojects](CMake-module.md#cmake-subprojects) due to these internal
 improvements:
 
 - Use the CMake file API for CMake >=3.14
@@ -177,14 +185,15 @@ improvements:
 
 ## compiler.get_linker_id()
 
-since 0.53.0, `compiler.get_linker_id()` allows retrieving a lowercase name for the linker.
+since 0.53.0, `compiler.get_linker_id()` allows retrieving a lowercase
-Since each compiler family can typically use a variety of linkers depending on operating system,
+name for the linker. Since each compiler family can typically use a
-this helps users define logic for corner cases not otherwise easily handled.
+variety of linkers depending on operating system, this helps users
+define logic for corner cases not otherwise easily handled.
 
 ## CUDA dependency
 
-Native support for compiling and linking against the CUDA Toolkit using 
+Native support for compiling and linking against the CUDA Toolkit
-the `dependency` function: 
+using the `dependency` function:
 
 ```meson
 project('CUDA test', 'cpp', meson_version: '>= 0.53.0')
@@ -208,4 +217,3 @@ scanning dependencies (--scan-dependencies):
 tests and benchmarks (--tests, --benchmarks, intro-tests.json,
 intro-benchmarks.json):
 - added the `protocol` key
-

docs/markdown/Release-notes-for-0.54.0.md

@@ -7,14 +7,16 @@ short-description: Release notes for 0.54.0
 
 ## Emscripten (emcc) now supports threads
 
-In addition to properly setting the compile and linker arguments, a new meson
+In addition to properly setting the compile and linker arguments, a
-builtin has been added to control the PTHREAD_POOL_SIZE option,
+new meson builtin has been added to control the PTHREAD_POOL_SIZE
-`-D<lang>_thread_count`, which may be set to any integer value greater than 0.
+option, `-D<lang>_thread_count`, which may be set to any integer value
-If it set to 0 then the PTHREAD_POOL_SIZE option will not be passed.
+greater than 0. If it set to 0 then the PTHREAD_POOL_SIZE option will
+not be passed.
 
 ## Introduce dataonly for the pkgconfig module
-This allows users to disable writing out the inbuilt variables to
+
-the pkg-config file as they might actually not be required.
+This allows users to disable writing out the inbuilt variables to the
+pkg-config file as they might actually not be required.
 
 One reason to have this is for architecture-independent pkg-config
 files in projects which also have architecture-dependent outputs.
@@ -30,24 +32,27 @@ pkgg.generate(
 
 ## Consistently report file locations relative to cwd
 
-The paths for filenames in error and warning locations are now consistently
+The paths for filenames in error and warning locations are now
-reported relative to the current working directory (when possible), or as
+consistently reported relative to the current working directory (when
-absolute paths (when a relative path does not exist, e.g. a Windows path
+possible), or as absolute paths (when a relative path does not exist,
-starting with a different drive letter to the current working directory).
+e.g. a Windows path starting with a different drive letter to the
+current working directory).
 
-(The previous behaviour was to report a path relative to the source root for all
+(The previous behaviour was to report a path relative to the source
-warnings and most errors, and relative to cwd for certain parser errors)
+root for all warnings and most errors, and relative to cwd for certain
+parser errors)
 
 ## `dependency()` consistency
 
-The first time a dependency is found, using `dependency('foo', ...)`, the return
+The first time a dependency is found, using `dependency('foo', ...)`,
-value is now cached. Any subsequent call will return the same value as long as
+the return value is now cached. Any subsequent call will return the
-version requested match, otherwise not-found dependency is returned. This means
+same value as long as version requested match, otherwise not-found
-that if a system dependency is first found, it won't fallback to a subproject
+dependency is returned. This means that if a system dependency is
-in a subsequent call any more and will rather return not-found instead if the
+first found, it won't fallback to a subproject in a subsequent call
-system version does not match. Similarly, if the first call returns the subproject
+any more and will rather return not-found instead if the system
-fallback dependency, it will also return the subproject dependency in a subsequent
+version does not match. Similarly, if the first call returns the
-call even if no fallback is provided.
+subproject fallback dependency, it will also return the subproject
+dependency in a subsequent call even if no fallback is provided.
 
 For example, if the system has `foo` version 1.0:
 ```meson
@@ -66,8 +71,8 @@ d2 = dependency('foo', version : '>=2.0', required : false,
 ## Override `dependency()`
 
 It is now possible to override the result of `dependency()` to point
-to any dependency object you want. The overriding is global and applies to
+to any dependency object you want. The overriding is global and
-every subproject from there on.
+applies to every subproject from there on.
 
 For example, this subproject provides 2 libraries with version 2.0:
 
@@ -89,28 +94,30 @@ foo_dep = dependency('foo', version : '>=2.0', fallback : ['foo', 'foo_dep'])
 bar_dep = dependency('bar')
 ```
 
-This used to mix system 1.0 version and subproject 2.0 dependencies, but thanks
+This used to mix system 1.0 version and subproject 2.0 dependencies,
-to the override `bar_dep` is now set to the subproject's version instead.
+but thanks to the override `bar_dep` is now set to the subproject's
+version instead.
 
-Another case this can be useful is to force a subproject to use a specific dependency.
+Another case this can be useful is to force a subproject to use a
-If the subproject does `dependency('foo')` but the main project wants to provide
+specific dependency. If the subproject does `dependency('foo')` but
-its own implementation of `foo`, it can for example call
+the main project wants to provide its own implementation of `foo`, it
-`meson.override_dependency('foo', declare_dependency(...))` before configuring the
+can for example call `meson.override_dependency('foo',
-subproject.
+declare_dependency(...))` before configuring the subproject.
 
 ## Simplified `dependency()` fallback
 
-In the case a subproject `foo` calls `meson.override_dependency('foo-2.0', foo_dep)`,
+In the case a subproject `foo` calls
-the parent project can omit the dependency variable name in fallback keyword
+`meson.override_dependency('foo-2.0', foo_dep)`, the parent project
-argument: `dependency('foo-2.0', fallback : 'foo')`.
+can omit the dependency variable name in fallback keyword argument:
+`dependency('foo-2.0', fallback : 'foo')`.
 
 ## Backend agnostic compile command
 
-A new `meson compile` command has been added to support backend agnostic
+A new `meson compile` command has been added to support backend
-compilation. It accepts two arguments, `-j` and `-l`, which are used if
+agnostic compilation. It accepts two arguments, `-j` and `-l`, which
-possible (`-l` does nothing with msbuild). A `-j` or `-l` value < 1 lets the
+are used if possible (`-l` does nothing with msbuild). A `-j` or `-l`
-backend decide how many threads to use. For msbuild this means `-m`, for
+value < 1 lets the backend decide how many threads to use. For msbuild
-ninja it means passing no arguments.
+this means `-m`, for ninja it means passing no arguments.
 
 ```console
 meson builddir --backend vs
@@ -122,7 +129,8 @@ meson builddir
 meson compile -C builddir -j3  # this is the same as `ninja -C builddir -j3`
 ```
 
-Additionally `meson compile` provides a `--clean` switch to clean the project.
+Additionally `meson compile` provides a `--clean` switch to clean the
+project.
 
 A complete list of arguments is always documented via `meson compile --help`
 
@@ -131,16 +139,16 @@ A complete list of arguments is always documented via `meson compile --help`
 `add_languages()` gained a `native:` keyword, indicating if a native or cross
 compiler is to be used.
 
-For the benefit of existing simple build definitions which don't contain any
+For the benefit of existing simple build definitions which don't
-`native: true` targets, without breaking backwards compatibility for build
+contain any `native: true` targets, without breaking backwards
-definitions which assume that the native compiler is available after
+compatibility for build definitions which assume that the native
-`add_languages()`, if the `native:` keyword is absent the languages may be used
+compiler is available after `add_languages()`, if the `native:`
-for either the build or host machine, but are never required for the build
+keyword is absent the languages may be used for either the build or
-machine.
+host machine, but are never required for the build machine.
 
-This changes the behaviour of the following meson fragment (when cross-compiling
+This changes the behaviour of the following meson fragment (when
-but a native compiler is not available) from reporting an error at
+cross-compiling but a native compiler is not available) from reporting
-`add_language` to reporting an error at `executable`.
+an error at `add_language` to reporting an error at `executable`.
 
 ```
 add_language('c')
@@ -149,42 +157,48 @@ executable('main', 'main.c', native: true)
 
 ## Summary improvements
 
-A new `list_sep` keyword argument has been added to `summary()` function.
+A new `list_sep` keyword argument has been added to `summary()`
-If defined and the value is a list, elements will be separated by the provided
+function. If defined and the value is a list, elements will be
-string instead of being aligned on a new line.
+separated by the provided string instead of being aligned on a new
+line.
 
-The automatic `subprojects` section now also print the number of warnings encountered
+The automatic `subprojects` section now also print the number of
-during that subproject configuration, or the error message if the configuration failed.
+warnings encountered during that subproject configuration, or the
+error message if the configuration failed.
 
 ## Add a system type dependency for zlib
 
-This allows zlib to be detected on macOS and FreeBSD without the use of
+This allows zlib to be detected on macOS and FreeBSD without the use
-pkg-config or cmake, neither of which are part of the base install on those
+of pkg-config or cmake, neither of which are part of the base install
-OSes (but zlib is).
+on those OSes (but zlib is).
 
-A side effect of this change is that `dependency('zlib')` also works with
+A side effect of this change is that `dependency('zlib')` also works
-cmake instead of requiring `dependency('ZLIB')`.
+with cmake instead of requiring `dependency('ZLIB')`.
 
 ## Added 'name' method
-Build target objects (as returned by executable(), library(), ...) now have a name() method.
+
+Build target objects (as returned by executable(), library(), ...) now
+have a name() method.
 
 ## New option `--quiet` to `meson install`
 
-Now you can run `meson install --quiet` and meson will not verbosely print
+Now you can run `meson install --quiet` and meson will not verbosely
-every file as it is being installed. As before, the full log is always
+print every file as it is being installed. As before, the full log is
-available inside the builddir in `meson-logs/install-log.txt`.
+always available inside the builddir in `meson-logs/install-log.txt`.
 
-When this option is passed, install scripts will have the environment variable
+When this option is passed, install scripts will have the environment
-`MESON_INSTALL_QUIET` set.
+variable `MESON_INSTALL_QUIET` set.
 
-Numerous speed-ups were also made for the install step, especially on Windows
+Numerous speed-ups were also made for the install step, especially on
-where it is now 300% to 1200% faster than before depending on your workload.
+Windows where it is now 300% to 1200% faster than before depending on
+your workload.
 
 ## Property support emscripten's wasm-ld
 
-Before 0.54.0 we treated emscripten as both compiler and linker, which isn't
+Before 0.54.0 we treated emscripten as both compiler and linker, which
-really true. It does have a linker, called wasm-ld (meson's name is ld.wasm).
+isn't really true. It does have a linker, called wasm-ld (meson's name
-This is a special version of clang's lld. This will now be detected properly.
+is ld.wasm). This is a special version of clang's lld. This will now
+be detected properly.
 
 ## Skip sanity tests when cross compiling
 
@@ -198,11 +212,12 @@ skip_sanity_check = true
 
 ## Support for overiding the linker with ldc and gdc
 
-LDC (the llvm D compiler) and GDC (The Gnu D Compiler) now honor D_LD linker
+LDC (the llvm D compiler) and GDC (The Gnu D Compiler) now honor D_LD
-variable (or d_ld in the cross file) and is able to pick different linkers.
+linker variable (or d_ld in the cross file) and is able to pick
+different linkers.
 
-GDC supports all of the same values as GCC, LDC supports ld.bfd, ld.gold,
+GDC supports all of the same values as GCC, LDC supports ld.bfd,
-ld.lld, ld64, link, and lld-link.
+ld.gold, ld.lld, ld64, link, and lld-link.
 
 ## Native file properties
 
@@ -212,42 +227,47 @@ As of Meson 0.54.0, the `--native-file nativefile.ini` can contain:
 * paths
 * properties
 
-which are defined and used the same way as in cross files.
+which are defined and used the same way as in cross files. The
-The `properties` are new for Meson 0.54.0, and are read like:
+`properties` are new for Meson 0.54.0, and are read like:
 
 ```meson
 x = meson.get_external_property('foobar', 'foo')
 ```
 
-where `foobar` is the property name, and the optional `foo` is the fallback string value.
+where `foobar` is the property name, and the optional `foo` is the
+fallback string value.
 
-For cross-compiled projects, `get_external_property()` reads the cross-file unless `native: true` is specified.
+For cross-compiled projects, `get_external_property()` reads the
+cross-file unless `native: true` is specified.
 
 ## Changed the signal used to terminate a test process (group)
 
-A test process (group) is now terminated via SIGTERM instead of SIGKILL
+A test process (group) is now terminated via SIGTERM instead of
-allowing the signal to be handled. However, it is now the responsibility of
+SIGKILL allowing the signal to be handled. However, it is now the
-the custom signal handler (if any) to ensure that any process spawned by the
+responsibility of the custom signal handler (if any) to ensure that
-top-level test processes is correctly killed.
+any process spawned by the top-level test processes is correctly
+killed.
 
 ## Dynamic Linker environment variables actually match docs
 
-The docs have always claimed that the Dynamic Linker environment variable
+The docs have always claimed that the Dynamic Linker environment
-should be `${COMPILER_VAR}_LD`, but that's only the case for about half of
+variable should be `${COMPILER_VAR}_LD`, but that's only the case for
-the variables. The other half are different. In 0.54.0 the variables match.
+about half of the variables. The other half are different. In 0.54.0
-The old variables are still supported, but are deprecated and raise a
+the variables match. The old variables are still supported, but are
-deprecation warning.
+deprecated and raise a deprecation warning.
 
 ## Per subproject `default_library` and `werror` options
 
-The `default_library` and `werror` built-in options can now be defined per subproject.
+The `default_library` and `werror` built-in options can now be defined
-This is useful for example when building shared libraries in the main project,
+per subproject. This is useful for example when building shared
-but static link a subproject, or when the main project must build with no warnings
+libraries in the main project, but static link a subproject, or when
-but some subprojects cannot.
+the main project must build with no warnings but some subprojects
+cannot.
 
-Most of the time this would be used either by the parent project by setting
+Most of the time this would be used either by the parent project by
-subproject's default_options (e.g. `subproject('foo', default_options: 'default_library=static')`),
+setting subproject's default_options (e.g. `subproject('foo',
-or by the user using the command line `-Dfoo:default_library=static`.
+default_options: 'default_library=static')`), or by the user using the
+command line `-Dfoo:default_library=static`.
 
 The value is overridden in this order:
 - Value from parent project
@@ -257,49 +277,53 @@ The value is overridden in this order:
 
 ## Environment Variables with Cross Builds
 
-Previously in Meson, variables like `CC` effected both the host and build
+Previously in Meson, variables like `CC` effected both the host and
-platforms for native builds, but the just the build platform for cross builds.
+build platforms for native builds, but the just the build platform for
-Now `CC_FOR_BUILD` is used for the build platform in cross builds.
+cross builds. Now `CC_FOR_BUILD` is used for the build platform in
+cross builds.
 
 This old behavior is inconsistent with the way Autotools works, which
 undermines the purpose of distro-integration that is the only reason
-environment variables are supported at all in Meson. The new behavior is not
+environment variables are supported at all in Meson. The new behavior
-quite the same, but doesn't conflict: meson doesn't always repond to an
+is not quite the same, but doesn't conflict: meson doesn't always
-environment when Autoconf would, but when it does it interprets it as Autotools
+repond to an environment when Autoconf would, but when it does it
-would.
+interprets it as Autotools would.
 
 ## Added 'pkg_config_libdir' property
-Allows to define a list of folders used by pkg-config for a cross build
+
-and avoid a system directories use.
+Allows to define a list of folders used by pkg-config for a cross
+build and avoid a system directories use.
 
 ## More new sample Meson templates for (`Java`, `Cuda`, and more)
 
-Meson now ships with predefined project templates for `Java`,
+Meson now ships with predefined project templates for `Java`, `Cuda`,
-`Cuda`, `Objective-C++`, and `C#`, we provided with associated
+`Objective-C++`, and `C#`, we provided with associated values for
-values for corresponding languages, available for both library,
+corresponding languages, available for both library, and executable.
-and executable.
 
 ## Ninja version requirement bumped to 1.7
 
-Meson now uses the [Implicit outputs](https://ninja-build.org/manual.html#ref_outputs)
+Meson now uses the [Implicit
-feature of Ninja for some types of targets that have multiple outputs which may
+outputs](https://ninja-build.org/manual.html#ref_outputs) feature of
+Ninja for some types of targets that have multiple outputs which may
 not be listed on the command-line. This feature requires Ninja 1.7+.
 
-Note that the latest version of [Ninja available in Ubuntu 16.04](https://packages.ubuntu.com/search?keywords=ninja-build&searchon=names&suite=xenial-backports&section=all)
+Note that the latest version of [Ninja available in Ubuntu
-(the oldest Ubuntu LTS at the time of writing) is 1.7.1. If your distro does
+16.04](https://packages.ubuntu.com/search?keywords=ninja-build&searchon=names&suite=xenial-backports&section=all)
-not ship with a new-enough Ninja, you can download the latest release from
+(the oldest Ubuntu LTS at the time of writing) is 1.7.1. If your
-Ninja's GitHub page: https://github.com/ninja-build/ninja/releases
+distro does not ship with a new-enough Ninja, you can download the
+latest release from Ninja's GitHub page:
+https://github.com/ninja-build/ninja/releases
 
 ## Added `-C` argument to `meson init` command
 
-The meson init assumes that it is run inside the project
+The meson init assumes that it is run inside the project root
-root directory. If this isn't the case, you can now use
+directory. If this isn't the case, you can now use `-C` to specify the
-`-C` to specify the actual project source directory.
+actual project source directory.
 
 ## More than one argument to `message()` and `warning()`
 
-Arguments passed to `message()` and `warning()` will be printed separated by
+Arguments passed to `message()` and `warning()` will be printed
-space.
+separated by space.
 
 ## Added `has_tools` method to qt module
 
@@ -325,24 +349,27 @@ repository.
 **Note**: the functionality of this module is governed by [Meson's
   rules on mixing build systems](Mixing-build-systems.md).
 
-The `pkgconfig` module now generates uninstalled pc files as well. For any generated
+The `pkgconfig` module now generates uninstalled pc files as well. For
-`foo.pc` file, an extra `foo-uninstalled.pc` file is placed into
+any generated `foo.pc` file, an extra `foo-uninstalled.pc` file is
-`<builddir>/meson-uninstalled`. They can be used to build applications against
+placed into `<builddir>/meson-uninstalled`. They can be used to build
-libraries built by meson without installing them, by pointing `PKG_CONFIG_PATH`
+applications against libraries built by meson without installing them,
-to that directory. This is an experimental feature provided on a best-effort
+by pointing `PKG_CONFIG_PATH` to that directory. This is an
-basis, it might not work in all use-cases.
+experimental feature provided on a best-effort basis, it might not
+work in all use-cases.
 
 ## CMake find_package COMPONENTS support
 
-It is now possible to pass components to the CMake dependency backend via the
+It is now possible to pass components to the CMake dependency backend
-new `components` kwarg in the `dependency` function.
+via the new `components` kwarg in the `dependency` function.
 
 ## Added Microchip XC16 C compiler support
+
 Make sure compiler executables are setup correctly in your path
 Compiler is available from the Microchip website for free
 
 
 ## Added Texas Instruments C2000 C/C++ compiler support
+
 Make sure compiler executables are setup correctly in your path
 Compiler is available from Texas Instruments website for free
 
@@ -361,6 +388,7 @@ be replicated by setting `unity_size` to a large value, such as 10000.
 
 ## Verbose mode for `meson compile`
 
-The new option `--verbose` has been added to `meson compile` that will enable
+The new option `--verbose` has been added to `meson compile` that will
-more verbose compilation logs. Note that for VS backend it means that logs will
+enable more verbose compilation logs. Note that for VS backend it
-be less verbose by default (without `--verbose` option).
+means that logs will be less verbose by default (without `--verbose`
+option).

docs/markdown/Release-notes-for-0.55.0.md

@@ -8,14 +8,15 @@ short-description: Release notes for 0.55.0
 ## rpath removal now more careful
 
 On Linux-like systems, meson adds rpath entries to allow running apps
-in the build tree, and then removes those build-time-only
+in the build tree, and then removes those build-time-only rpath
-rpath entries when installing.  Rpath entries may also come
+entries when installing. Rpath entries may also come in via LDFLAGS
-in via LDFLAGS and via .pc files.  Meson used to remove those
+and via .pc files. Meson used to remove those latter rpath entries by
-latter rpath entries by accident, but is now more careful.
+accident, but is now more careful.
 
 ## Added ability to specify targets in `meson compile`
 
-It's now possible to specify targets in `meson compile`, which will result in building only the requested targets.
+It's now possible to specify targets in `meson compile`, which will
+result in building only the requested targets.
 
 Usage: `meson compile [TARGET [TARGET...]]`
 `TARGET` has the following syntax: `[PATH/]NAME[:TYPE]`.
@@ -35,10 +36,10 @@ can be invoked with `meson compile foo:shared_library foo:static_library bar`.
 
 ## Test protocol for gtest
 
-Due to the popularity of Gtest (google test) among C and C++ developers meson
+Due to the popularity of Gtest (google test) among C and C++
-now supports a special protocol for gtest. With this protocol meson injects
+developers meson now supports a special protocol for gtest. With this
-arguments to gtests to output JUnit, reads that JUnit, and adds the output to
+protocol meson injects arguments to gtests to output JUnit, reads that
-the JUnit it generates.
+JUnit, and adds the output to the JUnit it generates.
 
 ## meson.add_*_script methods accept new types
 
@@ -56,8 +57,8 @@ meson.add_postconf_script(find_program('foo'), files('bar'))
 ```
 
 The install script variant is also able to accept custom_targets,
-custom_target indexes, and build targets (executables, libraries), and can
+custom_target indexes, and build targets (executables, libraries), and
-use built executables a the script to run
+can use built executables a the script to run
 
 ```meson
 installer = executable('installer', ...)
@@ -67,11 +68,11 @@ meson.add_install_script('foo.py', installer)
 
 ## Machine file constants
 
-Native and cross files now support string and list concatenation using the `+`
+Native and cross files now support string and list concatenation using
-operator, and joining paths using the `/` operator.
+the `+` operator, and joining paths using the `/` operator. Entries
-Entries defined in the `[constants]` section can be used in any other section.
+defined in the `[constants]` section can be used in any other section.
-An entry defined in any other section can be used only within that same section and only
+An entry defined in any other section can be used only within that
-after it has been defined.
+same section and only after it has been defined.
 
 ```ini
 [constants]
@@ -88,26 +89,27 @@ c = toolchain + '/gcc'
 
 ## Configure CMake subprojects with meson.subproject_options
 
-Meson now supports passing configuration options to CMake and overriding
+Meson now supports passing configuration options to CMake and
-certain build details extracted from the CMake subproject.
+overriding certain build details extracted from the CMake subproject.
 
 The new CMake configuration options object is very similar to the
-[configuration data object](Reference-manual.md#configuration-data-object) object
+[configuration data
-returned by [`configuration_data`](Reference-manual.md#configuration_data). It
+object](Reference-manual.md#configuration-data-object) object returned
+by [`configuration_data`](Reference-manual.md#configuration_data). It
 is generated by the `subproject_options` function
 
-All configuration options have to be set *before* the subproject is configured
+All configuration options have to be set *before* the subproject is
-and must be passed to the `subproject` method via the `options` key. Altering
+configured and must be passed to the `subproject` method via the
-the configuration object won't have any effect on previous `cmake.subproject`
+`options` key. Altering the configuration object won't have any effect
-calls.
+on previous `cmake.subproject` calls.
 
-**Note:** The `cmake_options` kwarg for the `subproject` function is now
+**Note:** The `cmake_options` kwarg for the `subproject` function is
-deprecated since it is replaced by the new `options` system.
+now deprecated since it is replaced by the new `options` system.
 
 ## find_program: Fixes when the program has been overridden by executable
 
-When a program has been overridden by an executable, the returned object of
+When a program has been overridden by an executable, the returned
-find_program() had some issues:
+object of find_program() had some issues:
 
 ```meson
 # In a subproject:
@@ -135,16 +137,16 @@ but only when needed to avoid command line length limits.
 
 ## `unstable-kconfig` module renamed to `unstable-keyval`
 
-The `unstable-kconfig` module is now renamed to `unstable-keyval`.
+The `unstable-kconfig` module is now renamed to `unstable-keyval`. We
-We expect this module to become stable once it has some usage experience,
+expect this module to become stable once it has some usage experience,
 specifically in the next or the following release
 
 
 ## Fatal warnings in `gnome.generate_gir()`
 
-`gnome.generate_gir()` now has `fatal_warnings` keyword argument to abort when
+`gnome.generate_gir()` now has `fatal_warnings` keyword argument to
-a warning is produced. This is useful for example in CI environment where it's
+abort when a warning is produced. This is useful for example in CI
-important to catch potential issues.
+environment where it's important to catch potential issues.
 
 ## b_ndebug support for D language compilers
 
@@ -153,27 +155,29 @@ the compiler) when the b_ndebug flag is set.
 
 ## Meson test now produces JUnit xml from results
 
-Meson will now generate a JUnit compatible XML file from test results. it
+Meson will now generate a JUnit compatible XML file from test results.
-will be in the meson-logs directory and is called testlog.junit.xml.
+it will be in the meson-logs directory and is called
+testlog.junit.xml.
 
 ## Config tool based dependencies no longer search PATH for cross compiling
 
-Before 0.55.0 config tool based dependencies (llvm-config, cups-config, etc),
+Before 0.55.0 config tool based dependencies (llvm-config,
-would search system $PATH if they weren't defined in the cross file. This has
+cups-config, etc), would search system $PATH if they weren't defined
-been a source of bugs and has been deprecated. It is now removed, config tool
+in the cross file. This has been a source of bugs and has been
-binaries must be specified in the cross file now or the dependency will not
+deprecated. It is now removed, config tool binaries must be specified
-be found.
+in the cross file now or the dependency will not be found.
 
 ## Rename has_exe_wrapper -> can_run_host_binaries
 
-The old name was confusing as it didn't really match the behavior of the
+The old name was confusing as it didn't really match the behavior of
-function. The old name remains as an alias (the behavior hasn't changed), but
+the function. The old name remains as an alias (the behavior hasn't
-is now deprecated.
+changed), but is now deprecated.
 
 ## String concatenation in meson_options.txt
 
-It is now possible to use string concatenation (with the `+` opperator) in the
+It is now possible to use string concatenation (with the `+`
-meson_options.txt file. This allows splitting long option descriptions.
+opperator) in the meson_options.txt file. This allows splitting long
+option descriptions.
 
 ```meson
 option(
@@ -187,53 +191,57 @@ option(
 
 ## Wrap fallback URL
 
-Wrap files can now define `source_fallback_url` and `patch_fallback_url` to be
+Wrap files can now define `source_fallback_url` and
-used in case the main server is temporaly down.
+`patch_fallback_url` to be used in case the main server is temporaly
+down.
 
 ## Clang coverage support
 
-llvm-cov is now used to generate coverage information when clang is used as
+llvm-cov is now used to generate coverage information when clang is
-the compiler.
+used as the compiler.
 
 ## Local wrap source and patch files
 
-It is now possible to use the `patch_filename` and `source_filename` value in a
+It is now possible to use the `patch_filename` and `source_filename`
-`.wrap` file without `*_url` to specify a local source / patch file. All local
+value in a `.wrap` file without `*_url` to specify a local source /
-files must be located in the `subprojects/packagefiles` directory. The `*_hash`
+patch file. All local files must be located in the
-entries are optional with this setup.
+`subprojects/packagefiles` directory. The `*_hash` entries are
+optional with this setup.
 
 ## Local wrap patch directory
 
-Wrap files can now specify `patch_directory` instead of `patch_filename` in the
+Wrap files can now specify `patch_directory` instead of
-case overlay files are local. Every files in that directory, and subdirectories,
+`patch_filename` in the case overlay files are local. Every files in
-will be copied to the subproject directory. This can be used for example to add
+that directory, and subdirectories, will be copied to the subproject
-`meson.build` files to a project not using Meson build system upstream.
+directory. This can be used for example to add `meson.build` files to
-The patch directory must be placed in `subprojects/packagefiles` directory.
+a project not using Meson build system upstream. The patch directory
+must be placed in `subprojects/packagefiles` directory.
 
 ## Patch on all wrap types
 
-`patch_*` keys are not limited to `wrap-file` any more, they can be specified for
+`patch_*` keys are not limited to `wrap-file` any more, they can be
-all wrap types.
+specified for all wrap types.
 
 ## link_language argument added to all targets
 
-Previously the `link_language` argument was only supposed to be allowed in
+Previously the `link_language` argument was only supposed to be
-executables, because the linker used needs to be the linker for the language
+allowed in executables, because the linker used needs to be the linker
-that implements the main function. Unfortunately it didn't work in that case,
+for the language that implements the main function. Unfortunately it
-and, even worse, if it had been implemented properly it would have worked for
+didn't work in that case, and, even worse, if it had been implemented
-*all* targets. In 0.55.0 this restriction has been removed, and the bug fixed.
+properly it would have worked for *all* targets. In 0.55.0 this
-It now is valid for `executable` and all derivative of `library`.
+restriction has been removed, and the bug fixed. It now is valid for
+`executable` and all derivative of `library`.
 
 ## meson dist --no-tests
 
-`meson dist` has a new option `--no-tests` to skip build and tests of generated
+`meson dist` has a new option `--no-tests` to skip build and tests of
-packages. It can be used to not waste time for example when done in CI that
+generated packages. It can be used to not waste time for example when
-already does its own testing.
+done in CI that already does its own testing.
 
 ## Force fallback for
 
-A newly-added `--force-fallback-for` command line option can now be used to
+A newly-added `--force-fallback-for` command line option can now be
-force fallback for specific subprojects.
+used to force fallback for specific subprojects.
 
 Example:
 
@@ -243,32 +251,36 @@ meson builddir/ --force-fallback-for=foo,bar
 
 ## Implicit dependency fallback
 
-`dependency('foo')` now automatically fallback if the dependency is not found on
+`dependency('foo')` now automatically fallback if the dependency is
-the system but a subproject wrap file or directory exists with the same name.
+not found on the system but a subproject wrap file or directory exists
+with the same name.
 
-That means that simply adding `subprojects/foo.wrap` is enough to add fallback
+That means that simply adding `subprojects/foo.wrap` is enough to add
-to any `dependency('foo')` call. It is however requires that the subproject call
+fallback to any `dependency('foo')` call. It is however requires that
-`meson.override_dependency('foo', foo_dep)` to specify which dependency object
+the subproject call `meson.override_dependency('foo', foo_dep)` to
-should be used for `foo`.
+specify which dependency object should be used for `foo`.
 
 ## Wrap file `provide` section
 
-Wrap files can define the dependencies it provides in the `[provide]` section.
+Wrap files can define the dependencies it provides in the `[provide]`
-When `foo.wrap` provides the dependency `foo-1.0` any call do `dependency('foo-1.0')`
+section. When `foo.wrap` provides the dependency `foo-1.0` any call do
-will automatically fallback to that subproject even if no `fallback` keyword
+`dependency('foo-1.0')` will automatically fallback to that subproject
-argument is given. See [Wrap documentation](Wrap-dependency-system-manual.md#provide_section).
+even if no `fallback` keyword argument is given. See [Wrap
+documentation](Wrap-dependency-system-manual.md#provide_section).
 
 ## `find_program()` fallback
 
-When a program cannot be found on the system but a wrap file has its name in the
+When a program cannot be found on the system but a wrap file has its
-`[provide]` section, that subproject will be used as fallback.
+name in the `[provide]` section, that subproject will be used as
+fallback.
 
 ## Test scripts are given the exe wrapper if needed
 
-Meson will now set the `MESON_EXE_WRAPPER` as the properly wrapped and joined
+Meson will now set the `MESON_EXE_WRAPPER` as the properly wrapped and
-representation. For Unix-like OSes this means python's shelx.join, on Windows
+joined representation. For Unix-like OSes this means python's
-an implementation that attempts to properly quote windows argument is used.
+shelx.join, on Windows an implementation that attempts to properly
-This allow wrapper scripts to run test binaries, instead of just skipping.
+quote windows argument is used. This allow wrapper scripts to run test
+binaries, instead of just skipping.
 
 for example, if the wrapper is `['emulator', '--script']`, it will be passed
 as `MESON_EXE_WRAPPER="emulator --script"`.
@@ -286,7 +298,8 @@ Usage: `meson compile [--vs-args=args] [--ninja-args=args]`
 
 These arguments use the following syntax:
 
-If you only pass a single string, then it is considered to have all values separated by commas. Thus invoking the following command:
+If you only pass a single string, then it is considered to have all
+values separated by commas. Thus invoking the following command:
 
 ```
 $ meson compile --ninja-args=-n,-d,explain
@@ -294,7 +307,8 @@ $ meson compile --ninja-args=-n,-d,explain
 
 would add `-n`, `-d` and `explain` arguments to ninja invocation.
 
-If you need to have commas or spaces in your string values, then you need to pass the value with proper shell quoting like this:
+If you need to have commas or spaces in your string values, then you
+need to pass the value with proper shell quoting like this:
 
 ```
 $ meson compile "--ninja-args=['a,b', 'c d']"
@@ -307,9 +321,12 @@ dumping the AST (--ast): **new in 0.55.0**
 
 ## `--backend=vs` now matches `-Db_vscrt=from_buildtype` behaviour in the Ninja backend
 
-When `--buildtype=debugoptimized` is used with the Ninja backend, the VS CRT
+When `--buildtype=debugoptimized` is used with the Ninja backend, the
-option used is `/MD`, which is the [behaviour documented for all
+VS CRT option used is `/MD`, which is the [behaviour documented for
+all
 backends](https://mesonbuild.com/Builtin-options.html#b_vscrt-from_buildtype).
-However, the Visual Studio backend was pass `/MT` in that case, which is inconsistent.
+However, the Visual Studio backend was pass `/MT` in that case, which
+is inconsistent.
 
-If you need to use the MultiThreaded CRT, you should explicitly pass `-Db_vscrt=mt`
+If you need to use the MultiThreaded CRT, you should explicitly pass
+`-Db_vscrt=mt`

docs/markdown/Release-notes-for-0.56.0.md

@@ -7,25 +7,28 @@ short-description: Release notes for 0.56.0
 
 ## Python 3.5 support will be dropped in the next release
 
-The final [Python 3.5 release was 3.5.10 in September](https://www.python.org/dev/peps/pep-0478/#id4).
+The final [Python 3.5 release was 3.5.10 in
-This release series is now End-of-Life (EOL). The only LTS distribution that
+September](https://www.python.org/dev/peps/pep-0478/#id4). This
-still only ships Python 3.5 is Ubuntu 16.04, which will be
+release series is now End-of-Life (EOL). The only LTS distribution
-[EOL in April 2021](https://ubuntu.com/about/release-cycle).
+that still only ships Python 3.5 is Ubuntu 16.04, which will be [EOL
-
+in April 2021](https://ubuntu.com/about/release-cycle).
-Python 3.6 has numerous features that we find useful such as improved support
+
-for the `typing` module, f-string support, and better integration with the
+Python 3.6 has numerous features that we find useful such as improved
-`pathlib` module.
+support for the `typing` module, f-string support, and better
-
+integration with the `pathlib` module.
-As a result, we will begin requiring Python 3.6 or newer in Meson 0.57, which
+
-is the next release. Starting with Meson 0.56, we now print a `NOTICE:` when
+As a result, we will begin requiring Python 3.6 or newer in Meson
-a `meson` command is run on Python 3.5 to inform users about this. This notice
+0.57, which is the next release. Starting with Meson 0.56, we now
-has also been backported into the 0.55.2 stable release.
+print a `NOTICE:` when a `meson` command is run on Python 3.5 to
+inform users about this. This notice has also been backported into the
+0.55.2 stable release.
 
 ## `meson test` can now filter tests by subproject
 
-You could always specify a list of tests to run by passing the names as
+You could always specify a list of tests to run by passing the names
-arguments to `meson test`. If there were multiple tests with that name (in the
+as arguments to `meson test`. If there were multiple tests with that
-same project or different subprojects), all of them would be run. Now you can:
+name (in the same project or different subprojects), all of them would
+be run. Now you can:
 
 1. Run all tests with the specified name from a specific subproject: `meson test subprojname:testname`
 1. Run all tests defined in a specific subproject: `meson test subprojectname:`
@@ -42,56 +45,62 @@ $ meson test name1 name2 bar:name3 foo:
 
 ## Native (build machine) compilers not always required by `project()`
 
-When cross-compiling, native (build machine) compilers for the languages
+When cross-compiling, native (build machine) compilers for the
-specified in `project()` are not required, if no targets use them.
+languages specified in `project()` are not required, if no targets use
+them.
 
 ## New `extra_files` key in target introspection
 
-The target introspection (`meson introspect --targets`, `intro-targets.json`)
+The target introspection (`meson introspect --targets`,
-now has the new `extra_files` key which lists all files specified via the
+`intro-targets.json`) now has the new `extra_files` key which lists
-`extra_files` kwarg of a build target (see `executable()`, etc.)
+all files specified via the `extra_files` kwarg of a build target (see
+`executable()`, etc.)
 
 
 ## Preliminary AIX support
 
-AIX is now supported when compiling with gcc. A number of features are not
+AIX is now supported when compiling with gcc. A number of features are
-supported yet. For example, only gcc is supported (not xlC). Archives with both
+not supported yet. For example, only gcc is supported (not xlC).
-32-bit and 64-bit dynamic libraries are not generated automatically. The rpath
+Archives with both 32-bit and 64-bit dynamic libraries are not
-includes both the build and install rpath, no attempt is made to change the
+generated automatically. The rpath includes both the build and install
-rpath at install time. Most advanced features (eg. link\_whole) are not
+rpath, no attempt is made to change the rpath at install time. Most
-supported yet.
+advanced features (eg. link\_whole) are not supported yet.
 
 ## Wraps from subprojects are automatically promoted
 
-It is not required to promote wrap files for subprojects into the main project
+It is not required to promote wrap files for subprojects into the main
-any more. When configuring a subproject, meson will look for any wrap file or
+project any more. When configuring a subproject, meson will look for
-directory in the subproject's `subprojects/` directory and add them into the
+any wrap file or directory in the subproject's `subprojects/`
-global list of available subprojects, to be used by any future `subproject()`
+directory and add them into the global list of available subprojects,
-call or `dependency()` fallback. If a subproject with the same name already exists,
+to be used by any future `subproject()` call or `dependency()`
-the new wrap file or directory is ignored. That means that the main project can
+fallback. If a subproject with the same name already exists, the new
-always override any subproject's wrap files by providing their own, it also means
+wrap file or directory is ignored. That means that the main project
-the ordering in which subprojects are configured matters, if 2 subprojects provide
+can always override any subproject's wrap files by providing their
-foo.wrap only the one from the first subproject to be configured will be used.
+own, it also means the ordering in which subprojects are configured
+matters, if 2 subprojects provide foo.wrap only the one from the first
+subproject to be configured will be used.
 
 This new behavior can be disabled by passing `--wrap-mode=nopromote`.
 
 ## `meson.build_root()` and `meson.source_root()` are deprecated
 
-Those function are common source of issue when used in a subproject because they
+Those function are common source of issue when used in a subproject
-point to the parent project root which is rarely what is expected and is a
+because they point to the parent project root which is rarely what is
-violation of subproject isolation.
+expected and is a violation of subproject isolation.
 
-`meson.current_source_dir()` and `meson.current_build_dir()` should be used instead
+`meson.current_source_dir()` and `meson.current_build_dir()` should be
-and have been available in all Meson versions. New functions `meson.project_source_root()`
+used instead and have been available in all Meson versions. New
-and `meson.project_build_root()` have been added in Meson 0.56.0 to get the root
+functions `meson.project_source_root()` and
-of the current (sub)project.
+`meson.project_build_root()` have been added in Meson 0.56.0 to get
+the root of the current (sub)project.
 
 ## `dep.as_link_whole()`
 
-Dependencies created with `declare_dependency()` now has new method `as_link_whole()`.
+Dependencies created with `declare_dependency()` now has new method
-It returns a copy of the dependency object with all link_with arguments changed
+`as_link_whole()`. It returns a copy of the dependency object with all
-to link_whole. This is useful for example for fallback dependency from a
+link_with arguments changed to link_whole. This is useful for example
-subproject built with `default_library=static`.
+for fallback dependency from a subproject built with
+`default_library=static`.
 
 ```meson
 somelib = static_library('somelib', ...)
@@ -128,11 +137,11 @@ Added support for `nvidia_hpc` NVidia HPC SDK compilers, which are currently in
 
 ## Project and built-in options can be set in native or cross files
 
-A new set of sections has been added to the cross and native files, `[project
+A new set of sections has been added to the cross and native files,
-options]` and `[<subproject_name>:project options]`, where `subproject_name`
+`[project options]` and `[<subproject_name>:project options]`, where
-is the name of a subproject. Any options that are allowed in the project can
+`subproject_name` is the name of a subproject. Any options that are
-be set from this section. They have the lowest precedent, and will be
+allowed in the project can be set from this section. They have the
-overwritten by command line arguments.
+lowest precedent, and will be overwritten by command line arguments.
 
 
 ```meson
@@ -189,26 +198,28 @@ stabilised (so `unstable-keyval` is still accepted for example).
 
 ## CMake subproject cross compilation support
 
-Meson now supports cross compilation for CMake subprojects. Meson will try to
+Meson now supports cross compilation for CMake subprojects. Meson will
-automatically guess most of the required CMake toolchain variables from existing
+try to automatically guess most of the required CMake toolchain
-entries in the cross and native files. These variables will be stored in an
+variables from existing entries in the cross and native files. These
-automatically generate CMake toolchain file in the build directory. The
+variables will be stored in an automatically generate CMake toolchain
-remaining variables that can't be guessed can be added by the user in the
+file in the build directory. The remaining variables that can't be
-new `[cmake]` cross/native file section.
+guessed can be added by the user in the new `[cmake]` cross/native
+file section.
 
 ## Machine file keys are stored case sensitive
 
-Previous the keys were always lowered, which worked fine for the values that
+Previous the keys were always lowered, which worked fine for the
-were allowed in the machine files. With the addition of per-project options
+values that were allowed in the machine files. With the addition of
-we need to make these sensitive to case, as the options in meson_options.txt
+per-project options we need to make these sensitive to case, as the
-are sensitive to case already.
+options in meson_options.txt are sensitive to case already.
 
 ## Consistency between `declare_dependency()` and `pkgconfig.generate()` variables
 
-The `variables` keyword argument in `declare_dependency()` used to only support
+The `variables` keyword argument in `declare_dependency()` used to
-dictionary and `pkgconfig.generate()` only list of strings. They now both support
+only support dictionary and `pkgconfig.generate()` only list of
-dictionary and list of strings in the format `'name=value'`. This makes easier
+strings. They now both support dictionary and list of strings in the
-to share a common set of variables for both:
+format `'name=value'`. This makes easier to share a common set of
+variables for both:
 
 ```meson
 vars = {'foo': 'bar'}
@@ -218,8 +229,9 @@ pkg.generate(..., variables: vars)
 
 ## Qt5 compile_translations now supports qresource preprocessing
 
-When using qtmod.preprocess() in combination with qtmod.compile_translations()
+When using qtmod.preprocess() in combination with
-to embed translations using rcc, it is no longer required to do this:
+qtmod.compile_translations() to embed translations using rcc, it is no
+longer required to do this:
 
 ```meson
 ts_files = ['list', 'of', 'files']
@@ -233,16 +245,16 @@ Instead, use:
 lang_cpp = qtmod.compile_translations(qresource: 'lang.qrc')
 ```
 
-which will automatically detect and generate the needed compile_translations
+which will automatically detect and generate the needed
-targets.
+compile_translations targets.
 
 ## Controlling subproject dependencies with  `dependency(allow_fallback: ...)`
 
 As an alternative to the `fallback` keyword argument to `dependency`,
 you may use `allow_fallback`, which accepts a boolean value. If `true`
-and the dependency is not found on the system, Meson will fallback
+and the dependency is not found on the system, Meson will fallback to
-to a subproject that provides this dependency, even if the dependency
+a subproject that provides this dependency, even if the dependency is
-is optional. If `false`, Meson will not fallback even if a subproject
+optional. If `false`, Meson will not fallback even if a subproject
 provides this dependency.
 
 ## Custom standard library
@@ -259,19 +271,19 @@ find_library for lookup as well as pkg-config.
 
 ## HDF5 dependency improvements
 
-HDF5 has been improved so that the internal representations have been split.
+HDF5 has been improved so that the internal representations have been
-This allows selecting pkg-config and config-tool dependencies separately.
+split. This allows selecting pkg-config and config-tool dependencies
-Both work as proper dependencies of their type, so `get_variable` and similar
+separately. Both work as proper dependencies of their type, so
-now work correctly.
+`get_variable` and similar now work correctly.
 
 It has also been fixed to use the selected compiler for the build instead of
 the default compiler.
 
 ## External projects
 
-A new experimental module `unstable_external_project` has been added to build
+A new experimental module `unstable_external_project` has been added
-code using other build systems than Meson. Currently only supporting projects
+to build code using other build systems than Meson. Currently only
-with a configure script that generates Makefiles.
+supporting projects with a configure script that generates Makefiles.
 
 ```meson
 project('My Autotools Project', 'c',
@@ -299,21 +311,23 @@ mylib_dep = p.dependency('mylib')
 
 ## `meson subprojects` command
 
-A new `--types` argument has been added to all subcommands to run the command only
+A new `--types` argument has been added to all subcommands to run the
-on wraps with the specified types. For example this command will only print `Hello`
+command only on wraps with the specified types. For example this
-for each git subproject: `meson subprojects foreach --types git echo "Hello"`.
+command will only print `Hello` for each git subproject: `meson
-Multiple types can be set as comma separated list e.g. `--types git,file`.
+subprojects foreach --types git echo "Hello"`. Multiple types can be
+set as comma separated list e.g. `--types git,file`.
 
-Subprojects with no wrap file are now taken into account as well. This happens
+Subprojects with no wrap file are now taken into account as well. This
-for example for subprojects configured as git submodule, or downloaded manually
+happens for example for subprojects configured as git submodule, or
-by the user and placed into the `subprojects/` directory.
+downloaded manually by the user and placed into the `subprojects/`
+directory.
 
-The `checkout` subcommand now always stash any pending changes before switching
+The `checkout` subcommand now always stash any pending changes before
-branch. Note that `update` subcommand was already stashing changes before updating
+switching branch. Note that `update` subcommand was already stashing
-the branch.
+changes before updating the branch.
 
-If the command fails on any subproject the execution continues with other
+If the command fails on any subproject the execution continues with
-subprojects, but at the end an error code is now returned.
+other subprojects, but at the end an error code is now returned.
 
 The `update` subcommand has been reworked:
 - In the case the URL of `origin` is different as the `url` set in wrap file,
@@ -336,22 +350,26 @@ The `update` subcommand has been reworked:
 
 ## Added CompCert C compiler
 
-Added experimental support for the [CompCert formally-verified C compiler](https://github.com/AbsInt/CompCert). The current state of the implementation is good enough to build the [picolibc project](https://github.com/picolibc/picolibc) with CompCert, but might still need additional adjustments for other projects.
+Added experimental support for the [CompCert formally-verified C
+compiler](https://github.com/AbsInt/CompCert). The current state of
+the implementation is good enough to build the [picolibc
+project](https://github.com/picolibc/picolibc) with CompCert, but
+might still need additional adjustments for other projects.
 
 ## Dependencies listed in test and benchmark introspection
 
-The introspection data for tests and benchmarks now includes the target
+The introspection data for tests and benchmarks now includes the
-ids for executables and built files that are needed by the test.  IDEs can
+target ids for executables and built files that are needed by the
-use this feature to update the build more quickly before running a test.
+test. IDEs can use this feature to update the build more quickly
+before running a test.
 
 ## `include_type` support for the CMake subproject object dependency method
 
-The `dependency()` method of the CMake subproject object now also supports the
+The `dependency()` method of the CMake subproject object now also
-`include_type` kwarg which is similar to the sane kwarg in the `dependency()`
+supports the `include_type` kwarg which is similar to the sane kwarg
-function.
+in the `dependency()` function.
 
 ## Deprecate Dependency.get_pkgconfig_variable and Dependency.get_configtool_variable
 
 These have been replaced with the more versatile `get_variable()` method
 already, and shouldn't be used anymore.
-

docs/markdown/Release-procedure.md

@@ -4,46 +4,50 @@
 
 # Trunk
 
-Meson operates under the principle that trunk should (in theory) be always
+Meson operates under the principle that trunk should (in theory) be
-good enough for release. That is, all code merged in trunk must pass all unit
+always good enough for release. That is, all code merged in trunk must
-tests. Any broken code should either be fixed or reverted immediately.
+pass all unit tests. Any broken code should either be fixed or
+reverted immediately.
 
-People who are willing to tolerate the occasional glitch should be able to
+People who are willing to tolerate the occasional glitch should be
-use Meson trunk for their day to day development if they so choose.
+able to use Meson trunk for their day to day development if they so
+choose.
 
 # Major releases
 
-Major releases are currently in the form 0.X.0, where X is an increasing
+Major releases are currently in the form 0.X.0, where X is an
-number. We aim to do a major release roughly once a month, though the
+increasing number. We aim to do a major release roughly once a month,
-schedule is not set in stone.
+though the schedule is not set in stone.
 
-Before a major release is made a stable branch will be made, and 0.X.0-rc1
+Before a major release is made a stable branch will be made, and
-release candidate will be made. A new milestone for 0.X.0 will be made, and
+0.X.0-rc1 release candidate will be made. A new milestone for 0.X.0
-all bugs effecting the RC will be assigned to this milestone. Patches fixing
+will be made, and all bugs effecting the RC will be assigned to this
-bugs in the milestone will be picked to the stable branch, and normal
+milestone. Patches fixing bugs in the milestone will be picked to the
-development will continue on the master branch. Every week after after this a
+stable branch, and normal development will continue on the master
-new release candidate will be made until all bugs are resolved in that
+branch. Every week after after this a new release candidate will be
-milestone. When all of the bugs are fixed the 0.X.0 release will be made.
+made until all bugs are resolved in that milestone. When all of the
+bugs are fixed the 0.X.0 release will be made.
 
 # Bugfix releases
 
-Bugfix releases contain only minor fixes to major releases and are designated
+Bugfix releases contain only minor fixes to major releases and are
-by incrementing the last digit of the version number. The criteria for a bug
+designated by incrementing the last digit of the version number. The
-fix release is one of the following:
+criteria for a bug fix release is one of the following:
 
  - release has a major regression compared to the previous release (making
    existing projects unbuildable)
  - the release has a serious bug causing data loss or equivalent
  - other unforeseen major issue
 
-In these cases a bug fix release can be made. It shall contain _only_ the fix
+In these cases a bug fix release can be made. It shall contain _only_
-for the issue (or issues) in question and other minor bug fixes. Only changes
+the fix for the issue (or issues) in question and other minor bug
-that have already landed in trunk will be considered for inclusion. No new
+fixes. Only changes that have already landed in trunk will be
-functionality shall be added.
+considered for inclusion. No new functionality shall be added.
 
 # Requesting a bug fix release
 
-The process for requesting that a bug fix release be made goes roughly as follows:
+The process for requesting that a bug fix release be made goes roughly
+as follows:
 
  - file a bug about the core issue
  - file a patch fixing it if possible
@@ -56,9 +60,10 @@ The request should contain the following information:
  - whether it has already caused problems for real projects
  - an estimate of how many people and projects will be affected
 
-There is no need to write a long and complicated request report. Something like the following is sufficient:
+There is no need to write a long and complicated request report.
+Something like the following is sufficient:
 
 > The latest release has a regression where trying to do Foo using Bar
-breaks. This breaks all projects that use both, which includes at least [list
+breaks. This breaks all projects that use both, which includes at
-of affected projects]. This causes problems for X amount of people and
+least [list of affected projects]. This causes problems for X amount
-because of this we should do a bugfix release.
+of people and because of this we should do a bugfix release.

docs/markdown/Rewriter.md

@@ -4,9 +4,9 @@ short-description: Automatic modification of the build system files
 
 # Meson file rewriter
 
-Since version 0.50.0, meson has the functionality to perform some basic
+Since version 0.50.0, meson has the functionality to perform some
-modification on the `meson.build` files from the command line. The currently
+basic modification on the `meson.build` files from the command line.
-supported operations are:
+The currently supported operations are:
 
 - For build targets:
   - Add/Remove source files
@@ -19,22 +19,23 @@ supported operations are:
   - Modify a select set of kwargs
   - Modify the default options list
 
-The rewriter has both, a normal command line interface and a "script mode". The
+The rewriter has both, a normal command line interface and a "script
-normal CLI is mostly designed for everyday use. The "script mode", on the
+mode". The normal CLI is mostly designed for everyday use. The "script
-other hand, is meant to be used by external programs (IDEs, graphical
+mode", on the other hand, is meant to be used by external programs
-frontends, etc.)
+(IDEs, graphical frontends, etc.)
 
-The rewriter itself is considered stable, however the user interface and the
+The rewriter itself is considered stable, however the user interface
-"script mode" API might change in the future. These changes may also break
+and the "script mode" API might change in the future. These changes
-backwards comaptibility to older releases.
+may also break backwards comaptibility to older releases.
 
 We are also open to suggestions for API improvements.
 
 ## Using the rewriter
 
-All rewriter functions are accessed via `meson rewrite`. The meson rewriter
+All rewriter functions are accessed via `meson rewrite`. The meson
-assumes that it is run inside the project root directory. If this isn't the
+rewriter assumes that it is run inside the project root directory. If
-case, use `--sourcedir` to specify the actual project source directory.
+this isn't the case, use `--sourcedir` to specify the actual project
+source directory.
 
 ### Adding and removing sources
 
@@ -67,17 +68,19 @@ src = ['main.cpp', 'fileA.cpp', 'fileB.cpp']
 exe1 = executable('testExe', src)
 ```
 
-In this case, `exe1` could also have been used for the target name. This is
+In this case, `exe1` could also have been used for the target name.
-possible because the rewriter also searches for assignments and unique meson
+This is possible because the rewriter also searches for assignments
-IDs, which can be acquired with introspection. If there are multiple targets
+and unique meson IDs, which can be acquired with introspection. If
-with the same name, meson will do nothing and print an error message.
+there are multiple targets with the same name, meson will do nothing
+and print an error message.
 
-For more information see the help output of the rewriter target command.
+For more information see the help output of the rewriter target
+command.
 
 ### Setting the project version
 
-It is also possible to set kwargs of specific functions with the rewriter. The
+It is also possible to set kwargs of specific functions with the
-general command for setting or removing kwargs is:
+rewriter. The general command for setting or removing kwargs is:
 
 ```bash
 meson rewrite kwargs {set/delete} <function type> <function ID> <key1> <value1> <key2> <value2> ...
@@ -97,10 +100,10 @@ Currently, only the following function types are supported:
 
 For more information see the help output of the rewrite kwargs command.
 
-Note msys bash may expand `/` to a path. Passing `//` will be converted to
+Note msys bash may expand `/` to a path. Passing `//` will be
-`/` by msys bash but in order to keep usage shell-agnostic, the rewrite command
+converted to `/` by msys bash but in order to keep usage
-also allows `//` as the function ID such that it will work in both msys bash
+shell-agnostic, the rewrite command also allows `//` as the function
-and other shells.
+ID such that it will work in both msys bash and other shells.
 
 ### Setting the project default options
 
@@ -112,9 +115,10 @@ meson rewrite default-options {set/delete} <opt1> <value1> <opt2> <value2> ...
 
 ## Limitations
 
-Rewriting a meson file is not guaranteed to keep the indentation of the modified
+Rewriting a meson file is not guaranteed to keep the indentation of
-functions. Additionally, comments inside a modified statement will be removed.
+the modified functions. Additionally, comments inside a modified
-Furthermore, all source files will be sorted alphabetically.
+statement will be removed. Furthermore, all source files will be
+sorted alphabetically.
 
 For instance adding `e.c` to srcs in the following code
 
@@ -150,9 +154,10 @@ srcs = [
 
 ## Using the "script mode"
 
-The "script mode" should be the preferred API for third party programs, since
+The "script mode" should be the preferred API for third party
-it offers more flexibility and higher API stability. The "scripts" are stored
+programs, since it offers more flexibility and higher API stability.
-in JSON format and executed with `meson rewrite command <JSON file or string>`.
+The "scripts" are stored in JSON format and executed with `meson
+rewrite command <JSON file or string>`.
 
 The JSON format is defined as follows:
 
@@ -229,13 +234,14 @@ The format for the type `default_options` is defined as follows:
 }
 ```
 
-For operation `delete`, the values of the `options` can be anything (including `null`)
+For operation `delete`, the values of the `options` can be anything
+(including `null`)
 
 ## Extracting information
 
-The rewriter also offers operation `info` for the types `target` and `kwargs`.
+The rewriter also offers operation `info` for the types `target` and
-When this operation is used, meson will print a JSON dump to stderr, containing
+`kwargs`. When this operation is used, meson will print a JSON dump to
-all available information to the rewriter about the build target / function
+stderr, containing all available information to the rewriter about the
-kwargs in question.
+build target / function kwargs in question.
 
 The output format is currently experimental and may change in the future.

docs/markdown/Run-targets.md

@@ -4,9 +4,13 @@ short-description: Targets to run external commands
 
 # Run targets
 
-Sometimes you need to have a target that just runs an external command. As an example you might have a build target that reformats your source code, runs `cppcheck` or something similar. In Meson this is accomplished with a so called *run target*.
+Sometimes you need to have a target that just runs an external
+command. As an example you might have a build target that reformats
+your source code, runs `cppcheck` or something similar. In Meson this
+is accomplished with a so called *run target*.
 
-The recommended way of doing this is writing the command(s) you want to run to a script file. Here's an example script.
+The recommended way of doing this is writing the command(s) you want
+to run to a script file. Here's an example script.
 
 ```bash
 #!/bin/sh
@@ -15,11 +19,21 @@ cd "${MESON_SOURCE_ROOT}"
 inspector_command -o "${MESON_BUILD_ROOT}/inspection_result.txt"
 ```
 
-Note the two environment variables `MESON_SOURCE_ROOT` and `MESON_BUILD_ROOT`. These are absolute paths to your project's source and build directories and they are automatically set up by Meson. In addition to these Meson also sets up the variable `MESON_SUBDIR`, which points to the subdirectory where the run command was specified. Most commands don't need to set up this.
+Note the two environment variables `MESON_SOURCE_ROOT` and
+`MESON_BUILD_ROOT`. These are absolute paths to your project's source
+and build directories and they are automatically set up by Meson. In
+addition to these Meson also sets up the variable `MESON_SUBDIR`,
+which points to the subdirectory where the run command was specified.
+Most commands don't need to set up this.
 
-Note how the script starts by cd'ing into the source dir. Meson does not guarantee that the script is run in any specific directory. Whether you need to do the same depends on what your custom target wants to do.
+Note how the script starts by cd'ing into the source dir. Meson does
+not guarantee that the script is run in any specific directory.
+Whether you need to do the same depends on what your custom target
+wants to do.
 
-To make this a run target we write it to a script file called `scripts/inspect.sh` and specify it in the top level Meson file like this.
+To make this a run target we write it to a script file called
+`scripts/inspect.sh` and specify it in the top level Meson file like
+this.
 
 ```meson
 run_target('inspector',
@@ -32,7 +46,8 @@ Run targets are not run by default. To run it run the following command.
 $ meson compile inspector
 ```
 
-All additional entries in `run_target`'s `command` array are passed unchanged to the inspector script, so you can do things like this:
+All additional entries in `run_target`'s `command` array are passed
+unchanged to the inspector script, so you can do things like this:
 
 ```meson
 run_target('inspector',

docs/markdown/Running-Meson.md

@@ -4,22 +4,25 @@ short-description: Building a project with Meson
 
 # Running Meson
 
-There are two different ways of invoking Meson. First, you can run it directly
+There are two different ways of invoking Meson. First, you can run it
-from the source tree with the command `/path/to/source/meson.py`. Meson may
+directly from the source tree with the command
-also be installed in which case the command is simply `meson`. In this manual
+`/path/to/source/meson.py`. Meson may also be installed in which case
-we only use the latter format for simplicity.
+the command is simply `meson`. In this manual we only use the latter
+format for simplicity.
 
-At the time of writing only a command line version of Meson is available. This
+At the time of writing only a command line version of Meson is
-means that Meson must be invoked using the terminal. If you wish to use the
+available. This means that Meson must be invoked using the terminal.
-MSVC compiler, you need to run Meson under "Visual Studio command prompt".
+If you wish to use the MSVC compiler, you need to run Meson under
+"Visual Studio command prompt".
 
-All available meson commands are listed on the [commands reference page](Commands.md).
+All available meson commands are listed on the [commands reference
+page](Commands.md).
 
 ## Configuring the build directory
 
-Let us assume that we have a source tree that has a Meson build system. This
+Let us assume that we have a source tree that has a Meson build
-means that at the topmost directory has a file called `meson.build`. We run the
+system. This means that at the topmost directory has a file called
-following commands to get the build started.
+`meson.build`. We run the following commands to get the build started.
 
 ```sh
 cd /path/to/source/root
@@ -30,18 +33,18 @@ We invoke Meson with the `setup` command, giving it the location of the build
 directory. Meson uses [out of source
 builds](http://voices.canonical.com/jussi.pakkanen/2013/04/16/why-you-should-consider-using-separate-build-directories/).
 
-Hint: The syntax of meson is `meson [command] [arguments] [options]`. The
+Hint: The syntax of meson is `meson [command] [arguments] [options]`.
-`setup` command takes a `builddir` and a `srcdir` argument. If no `srcdir` is
+The `setup` command takes a `builddir` and a `srcdir` argument. If no
-given Meson will deduce the `srcdir` based on `pwd` and the location of
+`srcdir` is given Meson will deduce the `srcdir` based on `pwd` and
-`meson.build`.
+the location of `meson.build`.
 
-Meson then loads the build configuration file and writes the corresponding
+Meson then loads the build configuration file and writes the
-build backend in the build directory. By default Meson generates a *debug
+corresponding build backend in the build directory. By default Meson
-build*, which turns on basic warnings and debug information and disables
+generates a *debug build*, which turns on basic warnings and debug
-compiler optimizations.
+information and disables compiler optimizations.
 
-Additionally, the invocation can pass options to meson. The list of options is
+Additionally, the invocation can pass options to meson. The list of
-documented [here](Builtin-options.md).
+options is documented [here](Builtin-options.md).
 
 You can specify a different type of build with the `--buildtype` command line
 argument. It can have one of the following values.
@@ -53,57 +56,61 @@ argument. It can have one of the following values.
 | `debugoptimized` | debug info is generated and the code is optimized (on most compilers this means `-g -O2`)                                                                  |
 | `release`        | full optimization, no debug info                                                                                                                           |
 
-The build directory is mandatory. The reason for this is that it simplifies the
+The build directory is mandatory. The reason for this is that it
-build process immensely. Meson will not under any circumstances write files
+simplifies the build process immensely. Meson will not under any
-inside the source directory (if it does, it is a bug and should be fixed). This
+circumstances write files inside the source directory (if it does, it
-means that the user does not need to add a bunch of files to their revision
+is a bug and should be fixed). This means that the user does not need
-control's ignore list. It also means that you can create arbitrarily many build
+to add a bunch of files to their revision control's ignore list. It
-directories for any given source tree.
+also means that you can create arbitrarily many build directories for
+any given source tree.
 
-For example, if we wanted to test building the source code with the Clang
+For example, if we wanted to test building the source code with the
-compiler instead of the system default, we could just type the following
+Clang compiler instead of the system default, we could just type the
-commands:
+following commands:
 
 ```sh
 cd /path/to/source/root
 CC=clang CXX=clang++ meson setup buildclang
 ```
 
-This separation is even more powerful if your code has multiple configuration
+This separation is even more powerful if your code has multiple
-options (such as multiple data backends). You can create a separate
+configuration options (such as multiple data backends). You can create
-subdirectory for each of them. You can also have build directories for
+a separate subdirectory for each of them. You can also have build
-optimized builds, code coverage, static analysis and so on. They are all neatly
+directories for optimized builds, code coverage, static analysis and
-separated and use the same source tree. Changing between different
+so on. They are all neatly separated and use the same source tree.
-configurations is just a question of changing to the corresponding directory.
+Changing between different configurations is just a question of
+changing to the corresponding directory.
 
-Unless otherwise mentioned, all following command line invocations are meant to
+Unless otherwise mentioned, all following command line invocations are
-be run in the source directory.
+meant to be run in the source directory.
 
-By default Meson will use the Ninja backend to build your project. If you wish
+By default Meson will use the Ninja backend to build your project. If
-to use any of the other backends, you need to pass the corresponding argument
+you wish to use any of the other backends, you need to pass the
-during configuration time. As an example, here is how you would use Meson to
+corresponding argument during configuration time. As an example, here
-generate a Visual studio solution.
+is how you would use Meson to generate a Visual studio solution.
 
 ```sh
 meson setup <build dir> --backend=vs
 ```
 
-You can then open the generated solution with Visual Studio and compile it in
+You can then open the generated solution with Visual Studio and
-the usual way. A list of backends can be obtained with `meson setup --help`.
+compile it in the usual way. A list of backends can be obtained with
+`meson setup --help`.
 
 ## Environment variables
 
-Sometimes you want to add extra compiler flags, this can be done by passing
+Sometimes you want to add extra compiler flags, this can be done by
-them in environment variables when calling meson. See [the reference
+passing them in environment variables when calling meson. See [the
-tables](Reference-tables.md#compiler-and-linker-flag-environment-variables) for
+reference
-a list of all the environment variables. Be aware however these environment
+tables](Reference-tables.md#compiler-and-linker-flag-environment-variables)
-variables are only used for the native compiler and will not affect the
+for a list of all the environment variables. Be aware however these
-compiler used for cross-compiling, where the flags specified in the cross file
+environment variables are only used for the native compiler and will
-will be used.
+not affect the compiler used for cross-compiling, where the flags
+specified in the cross file will be used.
 
-Furthermore it is possible to stop meson from adding flags itself by using the
+Furthermore it is possible to stop meson from adding flags itself by
-`--buildtype=plain` option, in this case you must provide the full compiler and
+using the `--buildtype=plain` option, in this case you must provide
-linker arguments needed.
+the full compiler and linker arguments needed.
 
 ## Building from the source
 
@@ -117,31 +124,34 @@ See [`meson compile` description](Commands.md#compile) for more info.
 
 ### Building directly with ninja
 
-By default Meson uses the [Ninja build system](https://ninja-build.org/) to 
+By default Meson uses the [Ninja build
-actually build the code. To start the build, simply type the following command.
+system](https://ninja-build.org/) to actually build the code. To start
+the build, simply type the following command.
 
 ```sh
 ninja -C builddir
 ```
 
-The main usability difference between Ninja and Make is that Ninja will
+The main usability difference between Ninja and Make is that Ninja
-automatically detect the number of CPUs in your computer and parallelize itself
+will automatically detect the number of CPUs in your computer and
-accordingly. You can override the amount of parallel processes used with the
+parallelize itself accordingly. You can override the amount of
-command line argument `-j <num processes>`.
+parallel processes used with the command line argument `-j <num
-
+processes>`.
-It should be noted that after the initial configure step `ninja` is the only
+
-command you ever need to type to compile. No matter how you alter your source
+It should be noted that after the initial configure step `ninja` is
-tree (short of moving it to a completely new location), Meson will detect the
+the only command you ever need to type to compile. No matter how you
-changes and regenerate itself accordingly. This is especially handy if you have
+alter your source tree (short of moving it to a completely new
-multiple build directories. Often one of them is used for development (the
+location), Meson will detect the changes and regenerate itself
-"debug" build) and others only every now and then (such as a "static analysis"
+accordingly. This is especially handy if you have multiple build
-build). Any configuration can be built just by `cd`'ing to the corresponding
+directories. Often one of them is used for development (the "debug"
-directory and running Ninja.
+build) and others only every now and then (such as a "static analysis"
+build). Any configuration can be built just by `cd`'ing to the
+corresponding directory and running Ninja.
 
 ## Running tests
 
-Meson provides native support for running tests. The command to do that is
+Meson provides native support for running tests. The command to do
-simple.
+that is simple.
 
 ```sh
 meson test -C builddir
@@ -149,8 +159,8 @@ meson test -C builddir
 
 See [`meson test` description](Commands.md#test) for more info.
 
-Meson does not force the use of any particular testing framework. You are free
+Meson does not force the use of any particular testing framework. You
-to use GTest, Boost Test, Check or even custom executables.
+are free to use GTest, Boost Test, Check or even custom executables.
 
 Note: it can be also invoked directly with ninja with the following command:
 ```sh
@@ -171,28 +181,30 @@ Note that Meson will only install build targets explicitly tagged as
 installable, as detailed in the [installing targets
 documentation](Installing.md).
 
-By default Meson installs to `/usr/local`. This can be changed by passing the
+By default Meson installs to `/usr/local`. This can be changed by
-command line argument `--prefix /your/prefix` to Meson during configure time.
+passing the command line argument `--prefix /your/prefix` to Meson
-Meson also supports the `DESTDIR` variable used in e.g. building packages. It
+during configure time. Meson also supports the `DESTDIR` variable used
-is used like this:
+in e.g. building packages. It is used like this:
 
 ```sh
 DESTDIR=/path/to/staging meson install -C builddir
 ```
 
-Note: it can be also invoked directly with ninja with the following command:
+Note: it can be also invoked directly with ninja with the following
+command:
+
 ```sh
 ninja -C builddir install
 ```
 
 ## Command line help
 
-Meson has a standard command line help feature. It can be accessed with the
+Meson has a standard command line help feature. It can be accessed
-following command.
+with the following command.
 
     meson --help
 
 ## Exit status
 
-Meson exits with status 0 if successful, 1 for problems with the command line
+Meson exits with status 0 if successful, 1 for problems with the
-or meson.build file, and 2 for internal errors.
+command line or meson.build file, and 2 for internal errors.

docs/markdown/Rust-module.md

@@ -12,20 +12,20 @@ authors:
 
 **Note** Unstable modules make no backwards compatible API guarantees.
 
-The rust module provides helper to integrate rust code into meson. The goal
+The rust module provides helper to integrate rust code into meson. The
-is to make using rust in meson more pleasant, while still remaining mesonic,
+goal is to make using rust in meson more pleasant, while still
-this means that it attempts to make rust work more like meson, rather than
+remaining mesonic, this means that it attempts to make rust work more
-meson work more like rust.
+like meson, rather than meson work more like rust.
 
 ## Functions
 
 ### test(name: string, target: library | executable, dependencies: []Dependency)
 
-This function creates a new rust unittest target from an existing rust based
+This function creates a new rust unittest target from an existing rust
-target, which may be a library or executable. It does this by copying the
+based target, which may be a library or executable. It does this by
-sources and arguments passed to the original target and adding the `--test`
+copying the sources and arguments passed to the original target and
-argument to the compilation, then creates a new test target which calls that
+adding the `--test` argument to the compilation, then creates a new
-executable, using the rust test protocol.
+test target which calls that executable, using the rust test protocol.
 
 This accepts all of the keyword arguments as the
 [`test`](Reference-manual.md#test) function except `protocol`, it will set

docs/markdown/Shipping-prebuilt-binaries-as-wraps.md

@@ -1,8 +1,17 @@
 # Shipping prebuilt binaries as wraps
 
-A common dependency case, especially on Windows, is the need to provide dependencies as prebuilt binaries rather than Meson projects that you build from scratch. Common reasons include not having access to source code, not having the time and effort to rewrite a legacy system's build definitions to Meson or just the fact that compiling the dependency projects takes too long.
+A common dependency case, especially on Windows, is the need to
+provide dependencies as prebuilt binaries rather than Meson projects
+that you build from scratch. Common reasons include not having access
+to source code, not having the time and effort to rewrite a legacy
+system's build definitions to Meson or just the fact that compiling
+the dependency projects takes too long.
 
-Packaging a project is straightforward. As an example let's look at a case where the project consists of one static library called `bob` and some headers. To create a binary dependency project we put the static library at the top level and headers in a subdirectory called `include`. The Meson build definition would look like the following.
+Packaging a project is straightforward. As an example let's look at a
+case where the project consists of one static library called `bob` and
+some headers. To create a binary dependency project we put the static
+library at the top level and headers in a subdirectory called
+`include`. The Meson build definition would look like the following.
 
 ```meson
 project('binary dep', 'c')
@@ -21,4 +30,7 @@ bob_dep = subproject('bob').get_variable('bin_dep')
 executable('prog', 'prog.c', dependencies : bob_dep)
 ```
 
-Note that often libraries compiled with different compilers (or even compiler flags) might not be compatible. If you do this, then you are responsible for verifying that your libraries are compatible, Meson will not check things for you.
+Note that often libraries compiled with different compilers (or even
+compiler flags) might not be compatible. If you do this, then you are
+responsible for verifying that your libraries are compatible, Meson
+will not check things for you.

docs/markdown/Simd-module.md

@@ -3,14 +3,15 @@
 This module provides helper functionality to build code with SIMD instructions.
 Available since 0.42.0.
 
-**Note**: this module is unstable. It is only provided as a technology preview.
+**Note**: this module is unstable. It is only provided as a technology
-Its API may change in arbitrary ways between releases or it might be removed
+preview. Its API may change in arbitrary ways between releases or it
-from Meson altogether.
+might be removed from Meson altogether.
 
 ## Usage
 
-This module is designed for the use case where you have an algorithm with one
+This module is designed for the use case where you have an algorithm
-or more SIMD implementation and you choose which one to use at runtime.
+with one or more SIMD implementation and you choose which one to use
+at runtime.
 
 The module provides one method, `check`, which is used like this:
 
@@ -27,20 +28,21 @@ The module provides one method, `check`, which is used like this:
       neon : 'simd_neon.c',
       compiler : cc)
 
-Here the individual files contain the accelerated versions of the functions
+Here the individual files contain the accelerated versions of the
-in question. The `compiler` keyword argument takes the compiler you are
+functions in question. The `compiler` keyword argument takes the
-going to use to compile them. The function returns an array with two values.
+compiler you are going to use to compile them. The function returns an
-The first value is a bunch of libraries that contain the compiled code. Any
+array with two values. The first value is a bunch of libraries that
-SIMD code that the compiler can't compile (for example, Neon instructions on
+contain the compiled code. Any SIMD code that the compiler can't
-an x86 machine) are ignored. You should pass this value to the desired target
+compile (for example, Neon instructions on an x86 machine) are
-using `link_with`. The second value is a `configuration_data` object that
+ignored. You should pass this value to the desired target using
-contains true for all the values that were supported. For example if the
+`link_with`. The second value is a `configuration_data` object that
-compiler did support sse2 instructions, then the object would have `HAVE_SSE2`
+contains true for all the values that were supported. For example if
-set to 1.
+the compiler did support sse2 instructions, then the object would have
+`HAVE_SSE2` set to 1.
 
 Generating code to detect the proper instruction set at runtime is
-straightforward. First you create a header with the configuration object and
+straightforward. First you create a header with the configuration
-then a chooser function that looks like this:
+object and then a chooser function that looks like this:
 
     void (*fptr)(type_of_function_here)  = NULL;
 
@@ -61,9 +63,9 @@ then a chooser function that looks like this:
         fptr = default_function;
     }
 
-Each source file provides two functions, the `xxx_available` function to query
+Each source file provides two functions, the `xxx_available` function
-whether the CPU currently in use supports the instruction set and
+to query whether the CPU currently in use supports the instruction set
-`xxx_accelerated_function` that is the corresponding accelerated
+and `xxx_accelerated_function` that is the corresponding accelerated
 implementation.
 
 At the end of this function the function pointer points to the fastest

docs/markdown/Simple-comparison.md

@@ -1,6 +1,7 @@
 # A simple comparison
 
-In this experiment we generated one thousand C files with contents that looked like this.
+In this experiment we generated one thousand C files with contents
+that looked like this.
 
 ```c
 #include<stdio.h>
@@ -9,34 +10,74 @@ In this experiment we generated one thousand C files with contents that looked l
 int func23() { return 0; }
 ```
 
-The function number was different in each file. In addition there was a main C file that just called each function in turn. We then generated build system files for *Meson*, *CMake*, *SCons*, *Premake* and *Autotools* that compiled these files into a single executable.
+The function number was different in each file. In addition there was
+a main C file that just called each function in turn. We then
+generated build system files for *Meson*, *CMake*, *SCons*, *Premake*
+and *Autotools* that compiled these files into a single executable.
 
-With this we measured three different things. The first is configuration time, that is, the time the build system takes to generate necessary build files. This is usually called the *configure step*. The time was measured in seconds.
+With this we measured three different things. The first is
+configuration time, that is, the time the build system takes to
+generate necessary build files. This is usually called the *configure
+step*. The time was measured in seconds.
 
-The second thing to measure was the build time. This should be limited by the compiler and in the optimal case should be the same for every build system. Four parallel processes were used in this test.
+The second thing to measure was the build time. This should be limited
+by the compiler and in the optimal case should be the same for every
+build system. Four parallel processes were used in this test.
 
-The third thing we measured was the empty build time. This measures how much time the build system takes to check the states of all source files because if any of them could potentially cause a rebuild.
+The third thing we measured was the empty build time. This measures
+how much time the build system takes to check the states of all source
+files because if any of them could potentially cause a rebuild.
 
-Since CMake has two different backends, Make and Ninja, we ran the tests on both of them. All tests were run on a 2011 era Macbook Pro running Ubuntu 13/04. The tests were run multiple times and we always took the fastest time.
+Since CMake has two different backends, Make and Ninja, we ran the
+tests on both of them. All tests were run on a 2011 era Macbook Pro
+running Ubuntu 13/04. The tests were run multiple times and we always
+took the fastest time.
 
 Here are the results for configuration time.
 
 ![Configuration times](images/conftime.png)
 
-The reason SCons got zero seconds on this test is because you cannot separate configure and build steps. They run as one unit. Autotools is the clear loser of this test as it is over an order of magnitude slower than the second slowest one. This configuration time includes both autogen and configure. All other systems take less than one second to do this setup, which is fast enough for a human being to interpret as instantaneous.
+The reason SCons got zero seconds on this test is because you cannot
+separate configure and build steps. They run as one unit. Autotools is
+the clear loser of this test as it is over an order of magnitude
+slower than the second slowest one. This configuration time includes
+both autogen and configure. All other systems take less than one
+second to do this setup, which is fast enough for a human being to
+interpret as instantaneous.
 
 ![Build times](https://raw.githubusercontent.com/wiki/jpakkane/meson/buildtime.png)
 
-Build times are a bit more even. SCons is the slowest, being almost ten seconds slower than the second slowest. Some of it is work from the configure step but it still has the worst performance. Premake is the fastest Make-based build system narrowly beating out Autotools. Both Ninja-based build systems are faster than all non-Ninja ones with Meson being slightly faster. In practice the difference is minimal. The advantages of Ninja can be seen by comparing CMake's times when using Make or Ninja. It is possible to shave off 3.5 seconds (over 20%) of the total build time just by changing the backend. The project's CMake configuration files don't need any changes.
+Build times are a bit more even. SCons is the slowest, being almost
+ten seconds slower than the second slowest. Some of it is work from
+the configure step but it still has the worst performance. Premake is
+the fastest Make-based build system narrowly beating out Autotools.
+Both Ninja-based build systems are faster than all non-Ninja ones with
+Meson being slightly faster. In practice the difference is minimal.
+The advantages of Ninja can be seen by comparing CMake's times when
+using Make or Ninja. It is possible to shave off 3.5 seconds (over
+20%) of the total build time just by changing the backend. The
+project's CMake configuration files don't need any changes.
 
 ![No-op time](https://raw.githubusercontent.com/wiki/jpakkane/meson/emptytime.png)
 
-Empty build times reflect the performance of regular build times. SCons is again the slowest taking over three seconds compared to Meson, which takes only 0.03 seconds, a difference of two orders of magnitude. Even Autotools, the fastest Make-based system, is almost one order of magnitude slower. Ninja holds the top spots just like in the previous test.
+Empty build times reflect the performance of regular build times.
+SCons is again the slowest taking over three seconds compared to
+Meson, which takes only 0.03 seconds, a difference of two orders of
+magnitude. Even Autotools, the fastest Make-based system, is almost
+one order of magnitude slower. Ninja holds the top spots just like in
+the previous test.
 
 Conclusions
 -----
 
-Build system performance matters. Even with this extremely simple example we can find differences between various popular build systems. As the project size increases, these differences grow even larger. (The author has witnessed no-op build times of 30 seconds for Make versus less than one second for Ninja when compiling the Clang compiler.) Keeping incremental build times low is one of the major keys of programmer productivity as it allows developers to iterate faster and stay in the creative zone.
+Build system performance matters. Even with this extremely simple
+example we can find differences between various popular build systems.
+As the project size increases, these differences grow even larger.
+(The author has witnessed no-op build times of 30 seconds for Make
+versus less than one second for Ninja when compiling the Clang
+compiler.) Keeping incremental build times low is one of the major
+keys of programmer productivity as it allows developers to iterate
+faster and stay in the creative zone.
 
 Original scripts
 -----

docs/markdown/SourceSet-module.md

@@ -8,10 +8,10 @@ authors:
 
 # Source set module
 
-This module provides support for building many targets against a single set
+This module provides support for building many targets against a
-of files; the choice of which files to include in each target depends on the
+single set of files; the choice of which files to include in each
-contents of a dictionary or a `configuration_data` object.  The module can
+target depends on the contents of a dictionary or a
-be loaded with:
+`configuration_data` object. The module can be loaded with:
 
 ``` meson
 ssmod = import('sourceset')
@@ -51,9 +51,9 @@ executable('exe', sources: sources, dependencies: dependencies())
 ```
 
 Sourcesets can be used with a single invocation of the `apply` method,
-similar to the example above, but the module is especially useful
+similar to the example above, but the module is especially useful when
-when multiple executables are generated by applying the same rules to
+multiple executables are generated by applying the same rules to many
-many different configurations.
+different configurations.
 
 *Added 0.51.0*
 
@@ -71,9 +71,9 @@ Create and return a new source set object.
 
 ## `source_set` object
 
-The `source_set` object provides methods to add files to a source set and
+The `source_set` object provides methods to add files to a source set
-to query it.  The source set becomes immutable after any method but `add`
+and to query it. The source set becomes immutable after any method but
-is called.
+`add` is called.
 
 ### Methods
 
@@ -86,27 +86,31 @@ source_set.add([when: varnames_and_deps],
 source_set.add(sources_and_deps)
 ```
 
-Add a *rule* to a source set.  A rule determines the conditions under which
+Add a *rule* to a source set. A rule determines the conditions under
-some source files or dependency objects are included in a build configuration.
+which some source files or dependency objects are included in a build
-All source files must be present in the source tree or they can be created
+configuration. All source files must be present in the source tree or
-in the build tree via `configure_file`, `custom_target` or `generator`.
+they can be created in the build tree via `configure_file`,
+`custom_target` or `generator`.
 
 `varnames_and_deps` is a list of conditions for the rule, which can be
-either strings or dependency objects (a dependency object is anything that
+either strings or dependency objects (a dependency object is anything
-has a `found()` method).  If *all* the strings evaluate to true and all
+that has a `found()` method). If *all* the strings evaluate to true
-dependencies are found, the rule will evaluate to true; `apply()`
+and all dependencies are found, the rule will evaluate to true;
-will then include the contents of the `if_true` keyword argument in its
+`apply()` will then include the contents of the `if_true` keyword
-result.  Otherwise, that is if any of the strings in the positional
+argument in its result. Otherwise, that is if any of the strings in
- arguments evaluate to false or any dependency is not found, `apply()`
+the positional arguments evaluate to false or any dependency is not
-will instead use the contents of the `if_false` keyword argument.
+found, `apply()` will instead use the contents of the `if_false`
-
+keyword argument.
-Dependencies can also appear in `sources_and_deps`.  In this case, a
+
-missing dependency will simply be ignored and will *not* disable the rule,
+Dependencies can also appear in `sources_and_deps`. In this case, a
-similar to how the `dependencies` keyword argument works in build targets.
+missing dependency will simply be ignored and will *not* disable the
-
+rule, similar to how the `dependencies` keyword argument works in
-**Note**: It is generally better to avoid mixing source sets and disablers.
+build targets.
-This is because disablers will cause the rule to be dropped altogether,
+
-and the `list_of_alt_sources` would not be taken into account anymore.
+**Note**: It is generally better to avoid mixing source sets and
+disablers. This is because disablers will cause the rule to be dropped
+altogether, and the `list_of_alt_sources` would not be taken into
+account anymore.
 
 #### `add_all()`
 
@@ -118,9 +122,9 @@ source_set.add_all(source_set1, source_set2, ...)
 
 Add one or more source sets to another.
 
-For each source set listed in the arguments, `apply()` will
+For each source set listed in the arguments, `apply()` will consider
-consider their rules only if the conditions in `varnames_and_deps` are
+their rules only if the conditions in `varnames_and_deps` are
-evaluated positively.  For example, the following:
+evaluated positively. For example, the following:
 
 ``` meson
 sources_b = ssmod.source_set()
@@ -144,7 +148,7 @@ list source_set.all_sources(...)
 
 Returns a list of all sources that were placed in the source set using
 `add` (including nested source sets) and that do not have a not-found
-dependency.  If a rule has a not-found dependency, only the `if_false`
+dependency. If a rule has a not-found dependency, only the `if_false`
 sources are included (if any).
 
 **Returns**: a list of file objects
@@ -166,16 +170,17 @@ using `add` (including nested source sets) and that were found.
 source_files source_set.apply(conf_data[, strict: false])
 ```
 
-Match the source set against a dictionary or a `configuration_data` object
+Match the source set against a dictionary or a `configuration_data`
-and return a *source configuration* object.  A source configuration object
+object and return a *source configuration* object. A source
-allows you to retrieve the sources and dependencies for a specific configuration.
+configuration object allows you to retrieve the sources and
+dependencies for a specific configuration.
 
 By default, all the variables that were specified in the rules have to
-be present in `conf_data`.  However, in some cases the convention is
+be present in `conf_data`. However, in some cases the convention is
 that `false` configuration symbols are absent in `conf_data`; this is
-the case for example when the configuration was loaded from a Kconfig file.
+the case for example when the configuration was loaded from a Kconfig
-In that case you can specify the `strict: false` keyword argument, which
+file. In that case you can specify the `strict: false` keyword
-will treat absent variables as false.
+argument, which will treat absent variables as false.
 
 **Returns**: a [source configuration][`source_configuration` object]
 

docs/markdown/Style-guide.md

@@ -22,18 +22,19 @@ Let say you would like to refer to your executable so something like `my_exe`.
 
 ## Dependency usage
 
-The `dependency` function is the recommended way to handle dependencies. If your wrap files
+The `dependency` function is the recommended way to handle
-have the necessary `[provide]` entries, everything will work automatically both when
+dependencies. If your wrap files have the necessary `[provide]`
-compiling your own and when using system dependencies.
+entries, everything will work automatically both when compiling your
+own and when using system dependencies.
 
 You should only need `subproject` when you need to extract non dependencies/programs.
 
 ## Naming options
 
 There are two ways of naming project options. As an example for
-booleans the first one is `foo` and the second one is
+booleans the first one is `foo` and the second one is `enable-foo`.
-`enable-foo`. The former style is recommended, because in Meson
+The former style is recommended, because in Meson options have strong
-options have strong type, rather than being just strings.
+type, rather than being just strings.
 
 You should try to name options the same as is common in other
 projects. This is especially important for yielding options, because
@@ -54,10 +55,11 @@ platform are isolated in one place.
 
 # Sorting source paths
 
-The source file arrays should all be sorted. This makes it easier to spot
+The source file arrays should all be sorted. This makes it easier to
-errors and often reduces merge conflicts. Furthermore, the paths should be
+spot errors and often reduces merge conflicts. Furthermore, the paths
-sorted with a natural sorting algorithm, so that numbers are sorted in an
+should be sorted with a natural sorting algorithm, so that numbers are
-intuitive way (`1, 2, 3, 10, 20` instead of `1, 10, 2, 20, 3`).
+sorted in an intuitive way (`1, 2, 3, 10, 20` instead of `1, 10, 2,
+20, 3`).
 
 Numbers should also be sorted before characters (`a111` before `ab0`).
 Furthermore, strings should be sorted case insensitive.

docs/markdown/Subprojects.md

@@ -25,8 +25,9 @@ supported but not guaranteed to work.
 
 ## A subproject example
 
-Usually dependencies consist of some header files plus a library to link against.
+Usually dependencies consist of some header files plus a library to
-To declare this internal dependency use `declare_dependency` function.
+link against. To declare this internal dependency use
+`declare_dependency` function.
 
 As an example, suppose we have a simple project that provides a shared
 library. Its `meson.build` would look like this.
@@ -46,12 +47,14 @@ libsimple_dep = declare_dependency(include_directories : inc,
 
 ### Naming convention for dependency variables
 
-Ideally the dependency variable name should be of `<project_name>_dep` form.
+Ideally the dependency variable name should be of `<project_name>_dep`
-This way one can just use it without even looking inside build definitions of that subproject.
+form. This way one can just use it without even looking inside build
+definitions of that subproject.
 
-In cases where there are multiple dependencies need to be declared, the default one
+In cases where there are multiple dependencies need to be declared,
-should be named as `<project_name>_dep` (e.g. `gtest_dep`), and others can have
+the default one should be named as `<project_name>_dep` (e.g.
-`<project_name>_<other>_<name>_dep` form (e.g. `gtest_main_dep` - gtest with main function).
+`gtest_dep`), and others can have `<project_name>_<other>_<name>_dep`
+form (e.g. `gtest_main_dep` - gtest with main function).
 
 There may be exceptions to these rules where common sense should be applied.
 
@@ -59,10 +62,11 @@ There may be exceptions to these rules where common sense should be applied.
 
 *New in 0.54.0*
 
-In some cases a project may define special variables via pkg-config or cmake
+In some cases a project may define special variables via pkg-config or
-that a caller needs to know about. Meson provides a `dependency.get_variable`
+cmake that a caller needs to know about. Meson provides a
-method to hide what kind of dependency is provided, and this is available to
+`dependency.get_variable` method to hide what kind of dependency is
-subprojects as well. Use the `variables` keyword to add a dict of strings:
+provided, and this is available to subprojects as well. Use the
+`variables` keyword to add a dict of strings:
 
 ```meson
 my_dep = declare_dependency(..., variables : {'var': 'value', 'number': '3'})
@@ -74,8 +78,8 @@ Which another project can access via:
 var = my_dep.get_variable(internal : 'var', cmake : 'CMAKE_VAR')
 ```
 
-The values of the dict must be strings, as pkg-config and cmake will return
+The values of the dict must be strings, as pkg-config and cmake will
-variables as strings.
+return variables as strings.
 
 ### Build options in subproject
 
@@ -89,8 +93,8 @@ as a subproject, use the `is_subproject` function.
 
 ## Using a subproject
 
-All subprojects must be inside `subprojects` directory.
+All subprojects must be inside `subprojects` directory. The
-The `subprojects` directory must be at the top level of your project.
+`subprojects` directory must be at the top level of your project.
 Subproject declaration must be in your top level `meson.build`.
 
 ### A simple example
@@ -171,12 +175,13 @@ executable('my_project',
   install : true)
 ```
 
-With this setup when libsimple is provided by the system, we use it. When
+With this setup when libsimple is provided by the system, we use it.
-that is not the case we use the embedded version (the one from subprojects).
+When that is not the case we use the embedded version (the one from
+subprojects).
 
-Note that `libsimple_dep` can point to an external or an internal dependency but
+Note that `libsimple_dep` can point to an external or an internal
-you don't have to worry about their differences. Meson will take care
+dependency but you don't have to worry about their differences. Meson
-of the details for you.
+will take care of the details for you.
 
 ### Subprojects depending on other subprojects
 
@@ -269,28 +274,29 @@ the following command-line options:
 
 *Since 0.49.0*
 
-`meson subprojects` has various subcommands to manage all subprojects. If the
+`meson subprojects` has various subcommands to manage all subprojects.
-subcommand fails on any subproject the execution continues with other subprojects.
+If the subcommand fails on any subproject the execution continues with
-All subcommands accept `--sourcedir` argument pointing to the root source dir
+other subprojects. All subcommands accept `--sourcedir` argument
-of the main project.
+pointing to the root source dir of the main project.
 
-*Since 0.56.0* all subcommands accept `--types <file|git|hg|svn>` argument to
+*Since 0.56.0* all subcommands accept `--types <file|git|hg|svn>`
-run the subcommands only on subprojects of the given types. Multiple types can
+argument to run the subcommands only on subprojects of the given
-be set as comma separated list e.g. `--types git,file`.
+types. Multiple types can be set as comma separated list e.g. `--types
+git,file`.
 
-*Since 0.56.0* If the subcommand fails on any subproject an error code is returned
+*Since 0.56.0* If the subcommand fails on any subproject an error code
-at the end instead of retuning success.
+is returned at the end instead of retuning success.
 
 ### Download subprojects
 
 *Since 0.49.0*
 
-Meson will automatically download needed subprojects during configure, unless
+Meson will automatically download needed subprojects during configure,
-**--wrap-mode=nodownload** option is passed. It is sometimes preferable to
+unless **--wrap-mode=nodownload** option is passed. It is sometimes
-download all subprojects in advance, so the meson configure can be performed
+preferable to download all subprojects in advance, so the meson
-offline. The command-line `meson subprojects download` can be used for that, it
+configure can be performed offline. The command-line `meson
-will download all missing subprojects, but will not update already fetched
+subprojects download` can be used for that, it will download all
-subprojects.
+missing subprojects, but will not update already fetched subprojects.
 
 ### Update subprojects
 
@@ -330,11 +336,11 @@ To pull latest version of all your subprojects at once, just run the command:
 
 *Since 0.49.0*
 
-The command-line `meson subprojects checkout <branch_name>` will checkout a
+The command-line `meson subprojects checkout <branch_name>` will
-branch, or create one with `-b` argument, in every git subprojects. This is
+checkout a branch, or create one with `-b` argument, in every git
-useful when starting local changes across multiple subprojects. It is still your
+subprojects. This is useful when starting local changes across
-responsibility to commit and push in each repository where you made local
+multiple subprojects. It is still your responsibility to commit and
-changes.
+push in each repository where you made local changes.
 
 To come back to the revision set in wrap file (i.e. master), just run
 `meson subprojects checkout` with no branch name.
@@ -346,9 +352,9 @@ To come back to the revision set in wrap file (i.e. master), just run
 *Since 0.51.0*
 
 The command-line `meson subprojects foreach <command> [...]` will
-execute a command in each subproject directory. For example this can be useful
+execute a command in each subproject directory. For example this can
-to check the status of subprojects (e.g. with `git status` or `git diff`) before
+be useful to check the status of subprojects (e.g. with `git status`
-performing other actions on them.
+or `git diff`) before performing other actions on them.
 
 ## Why must all subprojects be inside a single directory?
 

docs/markdown/Syntax.md

@@ -18,8 +18,9 @@ have multiple statements on one line as in e.g. *C*. Function and
 method calls' argument lists can be split over multiple lines. Meson
 will autodetect this case and do the right thing.
 
-In other cases, *(added 0.50)* you can get multi-line statements by ending the
+In other cases, *(added 0.50)* you can get multi-line statements by
-line with a `\`.  Apart from line ending whitespace has no syntactic meaning.
+ending the line with a `\`. Apart from line ending whitespace has no
+syntactic meaning.
 
 ## Variables
 
@@ -365,10 +366,11 @@ The following methods are defined for all arrays:
 
 ## Dictionaries
 
-Dictionaries are delimited by curly braces. A dictionary can contain an
+Dictionaries are delimited by curly braces. A dictionary can contain
-arbitrary number of key: value pairs. Keys are required to be strings, but values can
+an arbitrary number of key: value pairs. Keys are required to be
-be objects of any type. Prior to *0.53.0* keys were required to be literal
+strings, but values can be objects of any type. Prior to *0.53.0* keys
-strings, i.e., you could not use a variable containing a string value as a key.
+were required to be literal strings, i.e., you could not use a
+variable containing a string value as a key.
 
 ```meson
 my_dict = {'foo': 42, 'bar': 'baz'}
@@ -403,8 +405,8 @@ if 'foo' not in my_dict
 endif
 ```
 
-*Since 0.53.0* Keys can be any expression evaluating to a string value, not limited
+*Since 0.53.0* Keys can be any expression evaluating to a string
-to string literals any more.
+value, not limited to string literals any more.
 
 ```meson
 d = {'a' + 'b' : 42}
@@ -616,24 +618,25 @@ subdir('tests')
 
 ## User-defined functions and methods
 
-Meson does not currently support user-defined functions or
+Meson does not currently support user-defined functions or methods.
-methods. The addition of user-defined functions would make Meson
+The addition of user-defined functions would make Meson
 Turing-complete which would make it harder to reason about and more
 difficult to integrate with tools like IDEs. More details about this
 are [in the
-FAQ](FAQ.md#why-is-meson-not-just-a-python-module-so-i-could-code-my-build-setup-in-python). If
+FAQ](FAQ.md#why-is-meson-not-just-a-python-module-so-i-could-code-my-build-setup-in-python).
-because of this limitation you find yourself copying and pasting code
+If because of this limitation you find yourself copying and pasting
-a lot you may be able to use a [`foreach` loop
+code a lot you may be able to use a [`foreach` loop
 instead](#foreach-statements).
 
 ## Stability Promises
 
 Meson is very actively developed and continuously improved. There is a
-possibility that future enhancements to the Meson build system will require
+possibility that future enhancements to the Meson build system will
-changes to the syntax. Such changes might be the addition of new reserved
+require changes to the syntax. Such changes might be the addition of
-keywords, changing the meaning of existing keywords or additions around the
+new reserved keywords, changing the meaning of existing keywords or
-basic building blocks like statements and fundamental types. It is planned
+additions around the basic building blocks like statements and
-to stabilize the syntax with the 1.0 release.
+fundamental types. It is planned to stabilize the syntax with the 1.0
+release.
 
 ## Grammar
 

docs/markdown/Threads.md

@@ -4,7 +4,9 @@ short-description: Enabling thread support
 
 # Threads
 
-Meson has a very simple notational shorthand for enabling thread support on your build targets. First you obtain the thread dependency object like this:
+Meson has a very simple notational shorthand for enabling thread
+support on your build targets. First you obtain the thread dependency
+object like this:
 
 ```meson
 thread_dep = dependency('threads')

docs/markdown/Tutorial.md

@@ -48,8 +48,9 @@ project('tutorial', 'c')
 executable('demo', 'main.c')
 ```
 
-That is all. Note that unlike Autotools you [do not need to add any source
+That is all. Note that unlike Autotools you [do not need to add any
-headers to the list of sources](FAQ.md#do-i-need-to-add-my-headers-to-the-sources-list-like-in-autotools).
+source headers to the list of
+sources](FAQ.md#do-i-need-to-add-my-headers-to-the-sources-list-like-in-autotools).
 
 We are now ready to build our application. First we need
 to initialize the build by going into the source directory and issuing
@@ -117,7 +118,7 @@ use GTK+. The new version looks like this.
 #include <gtk/gtk.h>
 
 //
-// Should provided the active view for a GTK application 
+// Should provided the active view for a GTK application
 //
 static void activate(GtkApplication* app, gpointer user_data)
 {
@@ -177,10 +178,10 @@ $ meson compile
 ```
 
 Once you have set up your build directory the first time, you don't
-ever need to run the `meson` command again. You always just run
+ever need to run the `meson` command again. You always just run `meson
-`meson compile`. Meson will automatically detect when you have done changes to
+compile`. Meson will automatically detect when you have done changes
-build definitions and will take care of everything so users don't have
+to build definitions and will take care of everything so users don't
-to care. In this case the following output is produced.
+have to care. In this case the following output is produced.
 
     [1/1] Regenerating build files
     The Meson build system

docs/markdown/Unit-tests.md

@@ -4,8 +4,8 @@ short-description: Meson's own unit-test system
 
 # Unit tests
 
-Meson comes with a fully functional unit test system. To use it simply build
+Meson comes with a fully functional unit test system. To use it simply
-an executable and then use it in a test.
+build an executable and then use it in a test.
 
 ```meson
 e = executable('prog', 'testprog.c')
@@ -40,17 +40,19 @@ can be disabled as discussed in [test()](Reference-manual.md#test).
 
 ## Coverage
 
-If you enable coverage measurements by giving Meson the command line flag
+If you enable coverage measurements by giving Meson the command line
-`-Db_coverage=true`, you can generate coverage reports after running the
+flag `-Db_coverage=true`, you can generate coverage reports after
-tests (running the tests is required to gather the list of functions that get
+running the tests (running the tests is required to gather the list of
-called). Meson will autodetect what coverage generator tools you have
+functions that get called). Meson will autodetect what coverage
-installed and will generate the corresponding targets. These targets are
+generator tools you have installed and will generate the corresponding
-`coverage-xml` and `coverage-text` which are both provided by
+targets. These targets are `coverage-xml` and `coverage-text` which
-[Gcovr](http://gcovr.com) (version 3.3 or higher) and `coverage-html`, which
+are both provided by [Gcovr](http://gcovr.com) (version 3.3 or higher)
-requires [Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and
+and `coverage-html`, which requires
-[GenHTML](https://linux.die.net/man/1/genhtml) or [Gcovr](http://gcovr.com).
+[Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and
-As a convenience, a high-level `coverage` target is also generated which will
+[GenHTML](https://linux.die.net/man/1/genhtml) or
-produce all 3 coverage report types, if possible.
+[Gcovr](http://gcovr.com). As a convenience, a high-level `coverage`
+target is also generated which will produce all 3 coverage report
+types, if possible.
 
 The output of these commands is written to the log directory `meson-logs` in
 your build directory.
@@ -58,21 +60,23 @@ your build directory.
 ## Parallelism
 
 To reduce test times, Meson will by default run multiple unit tests in
-parallel. It is common to have some tests which can not be run in parallel
+parallel. It is common to have some tests which can not be run in
-because they require unique hold on some resource such as a file or a D-Bus
+parallel because they require unique hold on some resource such as a
-name. You have to specify these tests with a keyword argument.
+file or a D-Bus name. You have to specify these tests with a keyword
+argument.
 
 ```meson
 test('unique test', t, is_parallel : false)
 ```
 
-Meson will then make sure that no other unit test is running at the same
+Meson will then make sure that no other unit test is running at the
-time. Non-parallel tests take longer to run so it is recommended that you
+same time. Non-parallel tests take longer to run so it is recommended
-write your unit tests to be parallel executable whenever possible.
+that you write your unit tests to be parallel executable whenever
+possible.
 
-By default Meson uses as many concurrent processes as there are cores on the
+By default Meson uses as many concurrent processes as there are cores
-test machine. You can override this with the environment variable
+on the test machine. You can override this with the environment
-`MESON_TESTTHREADS` like this.
+variable `MESON_TESTTHREADS` like this.
 
 ```console
 $ MESON_TESTTHREADS=5 meson test
@@ -82,10 +86,10 @@ $ MESON_TESTTHREADS=5 meson test
 
 *(added in version 0.52.0)*
 
-Tests can be assigned a priority that determines when a test is *started*.
+Tests can be assigned a priority that determines when a test is
-Tests with higher priority are started first, tests with lower priority
+*started*. Tests with higher priority are started first, tests with
-started later. The default priority is 0, meson makes no guarantee on the
+lower priority started later. The default priority is 0, meson makes
-ordering of tests with identical priority.
+no guarantee on the ordering of tests with identical priority.
 
 ```meson
 test('started second', t, priority : 0)
@@ -93,34 +97,35 @@ test('started third', t, priority : -50)
 test('started first', t, priority : 1000)
 ```
 
-Note that the test priority only affects the starting order of tests and
+Note that the test priority only affects the starting order of tests
-subsequent tests are affected by how long it takes previous tests to
+and subsequent tests are affected by how long it takes previous tests
-complete. It is thus possible that a higher-priority test is still running
+to complete. It is thus possible that a higher-priority test is still
-when lower-priority tests with a shorter runtime have completed.
+running when lower-priority tests with a shorter runtime have
+completed.
 
 ## Skipped tests and hard errors
 
 Sometimes a test can only determine at runtime that it can not be run.
 
-For the default `exitcode` testing protocol, the GNU standard approach in
+For the default `exitcode` testing protocol, the GNU standard approach
-this case is to exit the program with error code 77. Meson will detect this
+in this case is to exit the program with error code 77. Meson will
-and report these tests as skipped rather than failed. This behavior was added
+detect this and report these tests as skipped rather than failed. This
-in version 0.37.0.
+behavior was added in version 0.37.0.
 
-For TAP-based tests, skipped tests should print a single line starting with
+For TAP-based tests, skipped tests should print a single line starting
-`1..0 # SKIP`.
+with `1..0 # SKIP`.
 
-In addition, sometimes a test fails set up so that it should fail even if it
+In addition, sometimes a test fails set up so that it should fail even
-is marked as an expected failure. The GNU standard approach in this case is
+if it is marked as an expected failure. The GNU standard approach in
-to exit the program with error code 99. Again, Meson will detect this and
+this case is to exit the program with error code 99. Again, Meson will
-report these tests as `ERROR`, ignoring the setting of `should_fail`. This
+detect this and report these tests as `ERROR`, ignoring the setting of
-behavior was added in version 0.50.0.
+`should_fail`. This behavior was added in version 0.50.0.
 
 ## Testing tool
 
-The goal of the meson test tool is to provide a simple way to run tests in a
+The goal of the meson test tool is to provide a simple way to run
-variety of different ways. The tool is designed to be run in the build
+tests in a variety of different ways. The tool is designed to be run
-directory.
+in the build directory.
 
 The simplest thing to do is just to run all tests.
 
@@ -162,9 +167,10 @@ Multiple suites are specified like:
 $ meson test --suite foo --suite bar
 ```
 
-NOTE: If you choose to specify both suite(s) and specific test name(s), the
+NOTE: If you choose to specify both suite(s) and specific test
-test name(s) must be contained in the suite(s). This however is redundant--
+name(s), the test name(s) must be contained in the suite(s). This
-it would be more useful to specify either specific test names or suite(s).
+however is redundant-- it would be more useful to specify either
+specific test names or suite(s).
 
 ### Other test options
 
@@ -193,25 +199,26 @@ Meson also supports running the tests under GDB. Just doing this:
 $ meson test --gdb testname
 ```
 
-Meson will launch `gdb` all set up to run the test. Just type `run` in the
+Meson will launch `gdb` all set up to run the test. Just type `run` in
-GDB command prompt to start the program.
+the GDB command prompt to start the program.
 
-The second use case is a test that segfaults only rarely. In this case you
+The second use case is a test that segfaults only rarely. In this case
-can invoke the following command:
+you can invoke the following command:
 
 ```console
 $ meson test --gdb --repeat=10000 testname
 ```
 
-This runs the test up to 10 000 times under GDB automatically. If the program
+This runs the test up to 10 000 times under GDB automatically. If the
-crashes, GDB will halt and the user can debug the application. Note that
+program crashes, GDB will halt and the user can debug the application.
-testing timeouts are disabled in this case so `meson test` will not kill
+Note that testing timeouts are disabled in this case so `meson test`
-`gdb` while the developer is still debugging it. The downside is that if the
+will not kill `gdb` while the developer is still debugging it. The
-test binary freezes, the test runner will wait forever.
+downside is that if the test binary freezes, the test runner will wait
+forever.
 
-Sometimes, the GDB binary is not in the PATH variable or the user wants to
+Sometimes, the GDB binary is not in the PATH variable or the user
-use a GDB replacement. Therefore, the invoked GDB program can be specified
+wants to use a GDB replacement. Therefore, the invoked GDB program can
-*(added 0.52.0)*:
+be specified *(added 0.52.0)*:
 
 ```console
 $ meson test --gdb --gdb-path /path/to/gdb testname
@@ -221,41 +228,43 @@ $ meson test --gdb --gdb-path /path/to/gdb testname
 $ meson test --print-errorlogs
 ```
 
-Meson will report the output produced by the failing tests along with other
+Meson will report the output produced by the failing tests along with
-useful information as the environmental variables. This is useful, for
+other useful information as the environmental variables. This is
-example, when you run the tests on Travis-CI, Jenkins and the like.
+useful, for example, when you run the tests on Travis-CI, Jenkins and
+the like.
 
-For further information see the command line help of Meson by running `meson
+For further information see the command line help of Meson by running
-test -h`.
+`meson test -h`.
 
 ## Legacy notes
 
-If `meson test` does not work for you, you likely have a old version of
+If `meson test` does not work for you, you likely have a old version
-Meson. In that case you should call `mesontest` instead. If `mesontest`
+of Meson. In that case you should call `mesontest` instead. If
-doesn't work either you have a very old version prior to 0.37.0 and should
+`mesontest` doesn't work either you have a very old version prior to
-upgrade.
+0.37.0 and should upgrade.
 
 ## Test outputs
 
-Meson will write several different files with detailed results of running
+Meson will write several different files with detailed results of
-tests. These will be written into $builddir/meson-logs/
+running tests. These will be written into $builddir/meson-logs/
 
 ### testlog.json
 
-This is not a proper json file, but a file containing one valid json object
+This is not a proper json file, but a file containing one valid json
-per line. This is file is designed so each line is streamed out as each test
+object per line. This is file is designed so each line is streamed out
-is run, so it can be read as a stream while the test harness is running
+as each test is run, so it can be read as a stream while the test
+harness is running
 
 ### testlog.junit.xml
 
-This is a valid JUnit XML description of all tests run. It is not streamed
+This is a valid JUnit XML description of all tests run. It is not
-out, and is written only once all tests complete running.
+streamed out, and is written only once all tests complete running.
 
-When tests use the `tap` protocol each test will be recorded as a testsuite
+When tests use the `tap` protocol each test will be recorded as a
-container, with each case named by the number of the result.
+testsuite container, with each case named by the number of the result.
 
-When tests use the `gtest` protocol meson will inject arguments to the test
+When tests use the `gtest` protocol meson will inject arguments to the
-to generate it's own JUnit XML, which meson will include as part of this XML
+test to generate it's own JUnit XML, which meson will include as part
-file.
+of this XML file.
 
 *New in 0.55.0*

docs/markdown/Unity-builds.md

@@ -4,7 +4,12 @@ short-description: Unity builds are a technique for reducing build times
 
 # Unity builds
 
-Unity builds are a technique for cutting down build times. The way it works is relatively straightforward. Suppose we have source files `src1.c`, `src2.c` and `src3.c`. Normally we would run the compiler three times, once for each file. In a unity build we instead compile all these sources in a single unit. The simplest approach is to create a new source file that looks like this.
+Unity builds are a technique for cutting down build times. The way it
+works is relatively straightforward. Suppose we have source files
+`src1.c`, `src2.c` and `src3.c`. Normally we would run the compiler
+three times, once for each file. In a unity build we instead compile
+all these sources in a single unit. The simplest approach is to create
+a new source file that looks like this.
 
 ```c
 #include<src1.c>
@@ -12,8 +17,23 @@ Unity builds are a technique for cutting down build times. The way it works is r
 #include<src3.c>
 ```
 
-This is then compiled rather than the individual files. The exact speedup depends on the code base, of course, but it is not uncommon to obtain more than 50% speedup in compile times. This happens even though the Unity build uses only one CPU whereas individual compiles can be run in parallel. Unity builds can also lead to faster code, because the compiler can do more aggressive optimizations (e.g. inlining).
+This is then compiled rather than the individual files. The exact
+speedup depends on the code base, of course, but it is not uncommon to
+obtain more than 50% speedup in compile times. This happens even
+though the Unity build uses only one CPU whereas individual compiles
+can be run in parallel. Unity builds can also lead to faster code,
+because the compiler can do more aggressive optimizations (e.g.
+inlining).
 
-The downside is that incremental builds are as slow as full rebuilds (because that is what they are). Unity compiles also use more memory, which may become an issue in certain scenarios. There may also be some bugs in the source that need to be fixed before Unity compiles work. As an example, if both `src1.c` and `src2.c` contain a static function or variable of the same name, there will be a clash.
+The downside is that incremental builds are as slow as full rebuilds
+(because that is what they are). Unity compiles also use more memory,
+which may become an issue in certain scenarios. There may also be some
+bugs in the source that need to be fixed before Unity compiles work.
+As an example, if both `src1.c` and `src2.c` contain a static function
+or variable of the same name, there will be a clash.
 
-Meson has built-in support for unity builds. To enable them, just pass `--unity on` on the command line or enable unity builds with the GUI. No code changes are necessary apart from the potential clash issue discussed above. Meson will automatically generate all the necessary inclusion files for you.
+Meson has built-in support for unity builds. To enable them, just pass
+`--unity on` on the command line or enable unity builds with the GUI.
+No code changes are necessary apart from the potential clash issue
+discussed above. Meson will automatically generate all the necessary
+inclusion files for you.

docs/markdown/Use-of-Python.md

@@ -1,21 +1,48 @@
 # Use of Python
 
-Meson is implemented in Python. This has both positive and negative sides. The main thing people seem to be mindful about is the dependency on Python to build source code. This page discusses various aspects of this problem.
+Meson is implemented in Python. This has both positive and negative
+sides. The main thing people seem to be mindful about is the
+dependency on Python to build source code. This page discusses various
+aspects of this problem.
 
 # Dependency hell
 
-There have been many Python programs that are difficult to maintain on multiple platforms. The reasons come mostly from dependencies. The program may use dependencies that are hard to compile on certain platforms, are outdated, conflict with other dependencies, not available on a given Python version and so on.
+There have been many Python programs that are difficult to maintain on
+multiple platforms. The reasons come mostly from dependencies. The
+program may use dependencies that are hard to compile on certain
+platforms, are outdated, conflict with other dependencies, not
+available on a given Python version and so on.
 
-Meson avoids dependency problems with one simple rule: Meson is not allowed to have any dependencies outside the Python basic library. The only thing you need is Python 3 (and possibly Ninja).
+Meson avoids dependency problems with one simple rule: Meson is not
+allowed to have any dependencies outside the Python basic library. The
+only thing you need is Python 3 (and possibly Ninja).
 
 ## Reimplementability
 
-Meson has been designed in such a way that the implementation language is never exposed in the build definitions. This makes it possible (and maybe even easy) to reimplement Meson in any other programming language. There are currently no plans to reimplement Meson, but we will make sure that Python is not exposed inside the build definitions.
+Meson has been designed in such a way that the implementation language
+is never exposed in the build definitions. This makes it possible (and
+maybe even easy) to reimplement Meson in any other programming
+language. There are currently no plans to reimplement Meson, but we
+will make sure that Python is not exposed inside the build
+definitions.
 
 ## Cross platform tooling
 
-There is no one technical solution or programming language that works natively on all operating systems currently in use. When Autotools was designed in the late 80s, Unix shell was available pretty much anywhere. This is no longer the case.
+There is no one technical solution or programming language that works
-
+natively on all operating systems currently in use. When Autotools was
-It is also the case that as any project gets larger, sooner or later it requires code generation, scripting or other tooling. This seems to be inevitable. Because there is no scripting language that would be available everywhere, these tools either need to be rewritten for each platform (which is a lot of work and is prone to errors) or the project needs to take a dependency on _something_.
+designed in the late 80s, Unix shell was available pretty much
-
+anywhere. This is no longer the case.
-Any project that uses Meson (at least the current version) can rely on the fact that Python 3 will always be available, because you can't compile the project without it. All tooling can then be done in Python 3 with the knowledge that it will run on any platform without any extra dependencies (modulo the usual porting work). This reduces maintenance effort on multiplatform projects by a fair margin.
+
+It is also the case that as any project gets larger, sooner or later
+it requires code generation, scripting or other tooling. This seems to
+be inevitable. Because there is no scripting language that would be
+available everywhere, these tools either need to be rewritten for each
+platform (which is a lot of work and is prone to errors) or the
+project needs to take a dependency on _something_.
+
+Any project that uses Meson (at least the current version) can rely on
+the fact that Python 3 will always be available, because you can't
+compile the project without it. All tooling can then be done in Python
+3 with the knowledge that it will run on any platform without any
+extra dependencies (modulo the usual porting work). This reduces
+maintenance effort on multiplatform projects by a fair margin.

docs/markdown/Using-multiple-build-directories.md

@@ -1,44 +1,86 @@
 # Using multiple build directories
 
-One of the main design goals of Meson has been to build all projects out-of-source. This means that *all* files generated during the build are placed in a separate subdirectory. This goes against common Unix tradition where you build your projects in-source. Building out of source gives two major advantages.
+One of the main design goals of Meson has been to build all projects
-
+out-of-source. This means that *all* files generated during the build
-First of all this makes for very simple `.gitignore` files. In classical build systems you may need to have tens of lines of definitions, most of which contain wildcards. When doing out of source builds all of this busywork goes away. A common ignore file for a Meson project only contains a few lines that are the build directory and IDE project files.
+are placed in a separate subdirectory. This goes against common Unix
-
+tradition where you build your projects in-source. Building out of
-Secondly this makes it very easy to clean your projects: just delete the build subdirectory and you are done. There is no need to guess whether you need to run `make clean`, `make distclean`, `make mrproper` or something else. When you delete a build subdirectory there is no possible way to have any lingering state from your old builds.
+source gives two major advantages.
+
+First of all this makes for very simple `.gitignore` files. In
+classical build systems you may need to have tens of lines of
+definitions, most of which contain wildcards. When doing out of source
+builds all of this busywork goes away. A common ignore file for a
+Meson project only contains a few lines that are the build directory
+and IDE project files.
+
+Secondly this makes it very easy to clean your projects: just delete
+the build subdirectory and you are done. There is no need to guess
+whether you need to run `make clean`, `make distclean`, `make
+mrproper` or something else. When you delete a build subdirectory
+there is no possible way to have any lingering state from your old
+builds.
 
 The true benefit comes from somewhere else, though.
 
 ## Multiple build directories for the same source tree
 
-Since a build directory is fully self contained and treats the source tree as a read-only piece of data, it follows that you can have arbitrarily many build trees for any source tree at the same time. Since all build trees can have different configuration, this is extremely powerful. Now you might be wondering why one would want to have multiple build setups at the same time. Let's examine this by setting up a hypothetical project.
+Since a build directory is fully self contained and treats the source
+tree as a read-only piece of data, it follows that you can have
+arbitrarily many build trees for any source tree at the same time.
+Since all build trees can have different configuration, this is
+extremely powerful. Now you might be wondering why one would want to
+have multiple build setups at the same time. Let's examine this by
+setting up a hypothetical project.
 
-The first thing to do is to set up the default build, that is, the one we are going to use over 90% of the time. In this we use the system compiler and build with debug enabled and no optimizations so it builds as fast as possible. This is the default project type for Meson, so setting it up is simple.
+The first thing to do is to set up the default build, that is, the one
+we are going to use over 90% of the time. In this we use the system
+compiler and build with debug enabled and no optimizations so it
+builds as fast as possible. This is the default project type for
+Meson, so setting it up is simple.
 
     mkdir builddir
     meson builddir
 
-Another common setup is to build with debug and optimizations to, for example, run performance tests. Setting this up is just as simple.
+Another common setup is to build with debug and optimizations to, for
+example, run performance tests. Setting this up is just as simple.
 
     mkdir buildopt
     meson --buildtype=debugoptimized buildopt
 
-For systems where the default compiler is GCC, we would like to compile with Clang, too. So let's do that.
+For systems where the default compiler is GCC, we would like to
+compile with Clang, too. So let's do that.
 
     mkdir buildclang
     CC=clang CXX=clang++ meson buildclang
 
-You can add cross builds, too. As an example, let's set up a Linux -> Windows cross compilation build using MinGW.
+You can add cross builds, too. As an example, let's set up a Linux ->
+Windows cross compilation build using MinGW.
 
     mkdir buildwine
     meson --cross-file=mingw-cross.txt buildwine
 
-The cross compilation file sets up Wine so that not only can you compile your application, you can also run the unit test suite just by issuing the command `meson test`.
+The cross compilation file sets up Wine so that not only can you
-
+compile your application, you can also run the unit test suite just by
-To compile any of these build types, just cd into the corresponding build directory and run `meson compile` or instruct your IDE to do the same. Note that once you have set up your build directory once, you can just run Ninja and Meson will ensure that the resulting build is fully up to date according to the source. Even if you have not touched one of the directories in weeks and have done major changes to your build configuration, Meson will detect this and bring the build directory up to date (or print an error if it can't do that). This allows you to do most of your work in the default directory and use the others every now and then without having to babysit your build directories.
+issuing the command `meson test`.
+
+To compile any of these build types, just cd into the corresponding
+build directory and run `meson compile` or instruct your IDE to do the
+same. Note that once you have set up your build directory once, you
+can just run Ninja and Meson will ensure that the resulting build is
+fully up to date according to the source. Even if you have not touched
+one of the directories in weeks and have done major changes to your
+build configuration, Meson will detect this and bring the build
+directory up to date (or print an error if it can't do that). This
+allows you to do most of your work in the default directory and use
+the others every now and then without having to babysit your build
+directories.
 
 ## Specialized uses
 
-Separate build directories allows easy integration for various different kinds of tools. As an example, Clang comes with a static analyzer. It is meant to be run from scratch on a given source tree. The steps to run it with Meson are very simple.
+Separate build directories allows easy integration for various
+different kinds of tools. As an example, Clang comes with a static
+analyzer. It is meant to be run from scratch on a given source tree.
+The steps to run it with Meson are very simple.
 
     rm -rf buildscan
     mkdir buildscan
@@ -46,4 +88,6 @@ Separate build directories allows easy integration for various different kinds o
     cd buildscan
     scan-build ninja
 
-These commands are the same for every single Meson project, so they could even be put in a script turning static analysis into a single command.
+These commands are the same for every single Meson project, so they
+could even be put in a script turning static analysis into a single
+command.

docs/markdown/Using-the-WrapDB.md

@@ -1,10 +1,24 @@
 # Using the WrapDB
 
-The Wrap database is a web service that provides Meson build definitions to projects that do not have it natively. Using it is simple. The service can be found [here](https://wrapdb.mesonbuild.com).
+The Wrap database is a web service that provides Meson build
-
+definitions to projects that do not have it natively. Using it is
-The front page lists all projects that are on the service. Select the one you want and click it. The detail page lists available versions by branch and revision id. The branch names come from upstream releases and revision ids are version numbers internal to the database. Whenever the packaging is updated a new revision is released to the service a new revision with a bigger revision id is added. Usually you want to select the newest branch with the highest revision id.
+simple. The service can be found
-
+[here](https://wrapdb.mesonbuild.com).
-You can get the actual wrap file which tells Meson how to fetch the project by clicking on the download link on the page. As an example, the wrap file for [zlib-1.2.8, revision 4](https://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_wrap) looks like this. You can find detailed documentation about it in [the Wrap manual](Wrap-dependency-system-manual.md).
+
+The front page lists all projects that are on the service. Select the
+one you want and click it. The detail page lists available versions by
+branch and revision id. The branch names come from upstream releases
+and revision ids are version numbers internal to the database.
+Whenever the packaging is updated a new revision is released to the
+service a new revision with a bigger revision id is added. Usually you
+want to select the newest branch with the highest revision id.
+
+You can get the actual wrap file which tells Meson how to fetch the
+project by clicking on the download link on the page. As an example,
+the wrap file for [zlib-1.2.8, revision
+4](https://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_wrap)
+looks like this. You can find detailed documentation about it in [the
+Wrap manual](Wrap-dependency-system-manual.md).
 
     [wrap-file]
     directory = zlib-1.2.8
@@ -17,12 +31,17 @@ You can get the actual wrap file which tells Meson how to fetch the project by c
     patch_filename = zlib-1.2.8-4-wrap.zip
     patch_hash = 2327a42c8f73a4289ee8c9cd4abc43b324d0decc28d6e609e927f0a50321af4a
 
-Add this file to your project with the name `subprojects/zlib.wrap`. Then you can use it in your `meson.build` file with this directive:
+Add this file to your project with the name `subprojects/zlib.wrap`.
+Then you can use it in your `meson.build` file with this directive:
 
     zproj = subproject('zlib')
 
-When Meson encounters this it will automatically download, unpack and patch the source files.
+When Meson encounters this it will automatically download, unpack and
+patch the source files.
 
 ## Contributing build definitions
 
-The contents of the Wrap database are tracked in git repos of the [Mesonbuild project](https://github.com/mesonbuild). The actual process is simple and described in [submission documentation](Adding-new-projects-to-wrapdb.md).
+The contents of the Wrap database are tracked in git repos of the
+[Mesonbuild project](https://github.com/mesonbuild). The actual
+process is simple and described in [submission
+documentation](Adding-new-projects-to-wrapdb.md).

docs/markdown/Using-with-Visual-Studio.md

@@ -4,22 +4,24 @@ short-description: How to use meson in Visual Studio
 
 # Using with Visual Studio
 
-In order to generate Visual Studio projects, Meson needs to know the settings
+In order to generate Visual Studio projects, Meson needs to know the
-of your installed version of Visual Studio. The only way to get this
+settings of your installed version of Visual Studio. The only way to
-information is to run Meson under the Visual Studio Command Prompt.
+get this information is to run Meson under the Visual Studio Command
+Prompt.
 
-You can always find the Visual Studio Command Prompt by searching from the
+You can always find the Visual Studio Command Prompt by searching from
-Start Menu. However, the name is different for each Visual Studio version. With
+the Start Menu. However, the name is different for each Visual Studio
-Visual Studio 2019, look for "x64 Native Tools Command Prompt for VS 2019".
+version. With Visual Studio 2019, look for "x64 Native Tools Command
-The next steps are [the same as always](https://mesonbuild.com/Running-Meson.html#configuring-the-build-directory):
+Prompt for VS 2019". The next steps are [the same as
+always](https://mesonbuild.com/Running-Meson.html#configuring-the-build-directory):
 
 1. `cd` into your source directory
 1. `meson setup builddir`, which will create and setup the build directory
 1. `meson compile -C builddir`, to compile your code. You can also use `ninja -C builddir` here if you are using the default Ninja backend.
 
-If you wish to generate Visual Studio project files, pass `--backend vs`.
+If you wish to generate Visual Studio project files, pass `--backend
-At the time of writing the Ninja backend is more mature than the VS backend so
+vs`. At the time of writing the Ninja backend is more mature than the
-you might want to use it for serious work.
+VS backend so you might want to use it for serious work.
 
 # Using Clang-CL with Visual Studio
 

docs/markdown/Vala.md

@@ -29,17 +29,18 @@ runtime type system.
 
 
 ## Using libraries
-Meson uses the [`dependency()`](Reference-manual.md#dependency) function to find
+
-the relevant VAPI, C headers and linker flags when it encounters a Vala source
+Meson uses the [`dependency()`](Reference-manual.md#dependency)
-file in a build target. Vala needs a VAPI file and a C header or headers to use
+function to find the relevant VAPI, C headers and linker flags when it
-a library. The VAPI file helps map Vala code to the library's C programming
+encounters a Vala source file in a build target. Vala needs a VAPI
-interface. It is the
+file and a C header or headers to use a library. The VAPI file helps
-[`pkg-config`](https://www.freedesktop.org/wiki/Software/pkg-config/) tool that
+map Vala code to the library's C programming interface. It is the
-makes finding these installed files all work seamlessly behind the scenes. When
+[`pkg-config`](https://www.freedesktop.org/wiki/Software/pkg-config/)
-a `pkg-config` file doesn't exist for the library then the
+tool that makes finding these installed files all work seamlessly
-[`find_library()`](Reference-manual.md#find_library) method of the [compiler
+behind the scenes. When a `pkg-config` file doesn't exist for the
-object](Reference-manual.md#compiler-object) needs to be used. Examples are
+library then the [`find_library()`](Reference-manual.md#find_library)
-given later.
+method of the [compiler object](Reference-manual.md#compiler-object)
+needs to be used. Examples are given later.
 
 Note Vala uses libraries that follow the C Application Binary Interface (C ABI).
 The library, however, could be written in C, Vala, Rust, Go, C++ or any other
@@ -72,26 +73,29 @@ sources = files('app.vala')
 executable('app_name', sources, dependencies: dependencies)
 ```
 
-GTK+ is the graphical toolkit used by GNOME, elementary OS and other desktop
+GTK+ is the graphical toolkit used by GNOME, elementary OS and other
-environments. The binding to the library, the VAPI file, is distributed with
+desktop environments. The binding to the library, the VAPI file, is
-Vala.
+distributed with Vala.
 
-Other libraries may have a VAPI that is distributed with the library itself.
+Other libraries may have a VAPI that is distributed with the library
-Such libraries will have their VAPI file installed along with their other
+itself. Such libraries will have their VAPI file installed along with
-development files. The VAPI is installed in Vala's standard search path and so
+their other development files. The VAPI is installed in Vala's
-works just as seamlessly using the `dependency()` function.
+standard search path and so works just as seamlessly using the
+`dependency()` function.
 
 
 ### Targeting a version of GLib
-Meson's [`dependency()`](Reference-manual.md#dependency) function allows a
-version check of a library. This is often used to check a minimum version is
-installed. When setting a minimum version of GLib, Meson will also pass this to
-the Vala compiler using the `--target-glib` option.
 
-This is needed when using GTK+'s user interface definition files with Vala's
+Meson's [`dependency()`](Reference-manual.md#dependency) function
-`[GtkTemplate]`, `[GtkChild]` and `[GtkCallback]` attributes. This requires
+allows a version check of a library. This is often used to check a
-`--target-glib 2.38`, or a newer version, to be passed to Vala. With Meson this
+minimum version is installed. When setting a minimum version of GLib,
-is simply done with:
+Meson will also pass this to the Vala compiler using the
+`--target-glib` option.
+
+This is needed when using GTK+'s user interface definition files with
+Vala's `[GtkTemplate]`, `[GtkChild]` and `[GtkCallback]` attributes.
+This requires `--target-glib 2.38`, or a newer version, to be passed
+to Vala. With Meson this is simply done with:
 
 ```meson
 project('vala app', 'vala', 'c')
@@ -107,9 +111,9 @@ sources = files('app.vala')
 executable('app_name', sources, dependencies: dependencies)
 ```
 
-Using `[GtkTemplate]` also requires the GTK+ user interface definition files to
+Using `[GtkTemplate]` also requires the GTK+ user interface definition
-be built in to the binary as GResources. For completeness, the next example
+files to be built in to the binary as GResources. For completeness,
-shows this:
+the next example shows this:
 
 ```meson
 project('vala app', 'vala', 'c')
@@ -133,17 +137,19 @@ executable('app_name', sources, dependencies: dependencies)
 
 
 ### Adding to Vala's search path
-So far we have covered the cases where the VAPI file is either distributed with
-Vala or the library. A VAPI can also be included in the source files of your
-project. The convention is to put it in the `vapi` directory of your project.
 
-This is needed when a library does not have a VAPI or your project needs to link
+So far we have covered the cases where the VAPI file is either
-to another component in the project that uses the C ABI. For example if part of
+distributed with Vala or the library. A VAPI can also be included in
-the project is written in C.
+the source files of your project. The convention is to put it in the
+`vapi` directory of your project.
+
+This is needed when a library does not have a VAPI or your project
+needs to link to another component in the project that uses the C ABI.
+For example if part of the project is written in C.
 
-The Vala compiler's `--vapidir` option is used to add the project directory to
+The Vala compiler's `--vapidir` option is used to add the project
-the VAPI search path. In Meson this is done with the `add_project_arguments()`
+directory to the VAPI search path. In Meson this is done with the
-function:
+`add_project_arguments()` function:
 
 ```meson
 project('vala app', 'vala', 'c')
@@ -163,30 +169,33 @@ sources = files('app.vala')
 executable('app_name', sources, dependencies: dependencies)
 ```
 
-If the VAPI is for an external library then make sure that the VAPI name
+If the VAPI is for an external library then make sure that the VAPI
-corresponds to the pkg-config file name.
+name corresponds to the pkg-config file name.
 
-The [`vala-extra-vapis` repository](https://gitlab.gnome.org/GNOME/vala-extra-vapis)
+The [`vala-extra-vapis`
-is a community maintained repository of VAPIs that are not distributed.
+repository](https://gitlab.gnome.org/GNOME/vala-extra-vapis) is a
+community maintained repository of VAPIs that are not distributed.
 Developers use the repository to share early work on new bindings and
-improvements to existing bindings. So the VAPIs can frequently change. It is
+improvements to existing bindings. So the VAPIs can frequently change.
-recommended VAPIs from this repository are copied in to your project's source
+It is recommended VAPIs from this repository are copied in to your
-files.
+project's source files.
 
-This also works well for starting to write new bindings before they are shared
+This also works well for starting to write new bindings before they
-with the `vala-extra-vapis` repository.
+are shared with the `vala-extra-vapis` repository.
 
 
 ### Libraries without pkg-config files
+
 A library that does not have a corresponding pkg-config file may mean
-`dependency()` is unsuitable for finding the C and Vala interface files. In this
+`dependency()` is unsuitable for finding the C and Vala interface
-case it is necessary to use the `find_library()` method of the compiler object.
+files. In this case it is necessary to use the `find_library()` method
+of the compiler object.
 
-The first example uses Vala's POSIX binding. There is no pkg-config file because
+The first example uses Vala's POSIX binding. There is no pkg-config
-POSIX includes the standard C library on Unix systems. All that is needed is the
+file because POSIX includes the standard C library on Unix systems.
-VAPI file, `posix.vapi`. This is included with Vala and installed in Vala's
+All that is needed is the VAPI file, `posix.vapi`. This is included
-standard search path. Meson just needs to be told to only find the library for
+with Vala and installed in Vala's standard search path. Meson just
-the Vala compiler:
+needs to be told to only find the library for the Vala compiler:
 
 ```meson
 project('vala app', 'vala', 'c')
@@ -202,10 +211,11 @@ sources = files('app.vala')
 executable('app_name', sources, dependencies: dependencies)
 ```
 
-The next example shows how to link with a C library where no additional VAPI is
+The next example shows how to link with a C library where no
-needed. The standard maths functions are already bound in `glib-2.0.vapi`, but
+additional VAPI is needed. The standard maths functions are already
-the GNU C library requires linking to the maths library separately. In this
+bound in `glib-2.0.vapi`, but the GNU C library requires linking to
-example Meson is told to find the library only for the C compiler:
+the maths library separately. In this example Meson is told to find
+the library only for the C compiler:
 
 ```meson
 project('vala app', 'vala', 'c')
@@ -220,12 +230,15 @@ sources = files('app.vala')
 
 executable('app_name', sources, dependencies: dependencies)
 ```
-The `required: false` means the build will continue when using another C library
-that does not separate the maths library. See [Add math library (-lm)
-portably](howtox.md#add-math-library-lm-portably).
 
-The final example shows how to use a library that does not have a pkg-config
+The `required: false` means the build will continue when using another
-file and the VAPI is in the `vapi` directory of your project source files:
+C library that does not separate the maths library. See [Add math
+library (-lm) portably](howtox.md#add-math-library-lm-portably).
+
+The final example shows how to use a library that does not have a
+pkg-config file and the VAPI is in the `vapi` directory of your
+project source files:
+
 ```meson
 project('vala app', 'vala', 'c')
 
@@ -252,13 +265,18 @@ keyword added to include the project VAPI directory. This is not added
 automatically by `add_project_arguments()`.
 
 ### Working with the Vala Preprocessor
-Passing arguments to [Vala's preprocessor](https://wiki.gnome.org/Projects/Vala/Manual/Preprocessor) requires specifying the language as `vala`.  For example, the following statement sets the preprocessor symbol `USE_FUSE`:
+
+Passing arguments to [Vala's
+preprocessor](https://wiki.gnome.org/Projects/Vala/Manual/Preprocessor)
+requires specifying the language as `vala`. For example, the following
+statement sets the preprocessor symbol `USE_FUSE`:
 
 ```meson
 add_project_arguments('-D', 'USE_FUSE', language: 'vala')
 ```
 
-If you need to pass an argument to the C pre-processor then specify the language as c. For example to set FUSE_USE_VERSION to 26 use:
+If you need to pass an argument to the C pre-processor then specify
+the language as c. For example to set FUSE_USE_VERSION to 26 use:
 
 ```meson
 add_project_arguments('-DFUSE_USE_VERSION=26', language: 'c')
@@ -268,9 +286,10 @@ add_project_arguments('-DFUSE_USE_VERSION=26', language: 'c')
 
 
 ### Changing C header and VAPI names
-Meson's [`library`](Reference-manual.md#library) target automatically outputs
+
-the C header and the VAPI. They can be renamed by setting the `vala_header` and
+Meson's [`library`](Reference-manual.md#library) target automatically
-`vala_vapi` arguments respectively:
+outputs the C header and the VAPI. They can be renamed by setting the
+`vala_header` and `vala_vapi` arguments respectively:
 
 ```meson
 foo_lib = shared_library('foo', 'foo.vala',
@@ -280,26 +299,29 @@ foo_lib = shared_library('foo', 'foo.vala',
                   install: true,
                   install_dir: [true, true, true])
 ```
-In this example, the second and third elements of the `install_dir` array
+
-indicate the destination with `true` to use default directories (i.e. `include`
+In this example, the second and third elements of the `install_dir`
-and `share/vala/vapi`).
+array indicate the destination with `true` to use default directories
+(i.e. `include` and `share/vala/vapi`).
 
 
 ### GObject Introspection and language bindings
-A 'binding' allows another programming language to use a library written in
+
-Vala. Because Vala uses the GObject type system as its runtime type system it is
+A 'binding' allows another programming language to use a library
-very easy to use introspection to generate a binding. A Meson build of a Vala
+written in Vala. Because Vala uses the GObject type system as its
-library can generate the GObject introspection metadata. The metadata is then
+runtime type system it is very easy to use introspection to generate a
-used in separate projects with [language specific
+binding. A Meson build of a Vala library can generate the GObject
-tools](https://wiki.gnome.org/Projects/Vala/LibraryWritingBindings) to generate
+introspection metadata. The metadata is then used in separate projects
-a binding.
+with [language specific
-
+tools](https://wiki.gnome.org/Projects/Vala/LibraryWritingBindings) to
-The main form of metadata is a GObject Introspection Repository (GIR) XML file.
+generate a binding.
-GIRs are mostly used by languages that generate bindings at compile time.
+
-Languages that generate bindings at runtime mostly use a typelib file, which is
+The main form of metadata is a GObject Introspection Repository (GIR)
-generated from the GIR.
+XML file. GIRs are mostly used by languages that generate bindings at
-
+compile time. Languages that generate bindings at runtime mostly use a
-Meson can generate a GIR as part of the build.  For a Vala library the
+typelib file, which is generated from the GIR.
+
+Meson can generate a GIR as part of the build. For a Vala library the
 `vala_gir` option has to be set for the `library`:
 
 ```meson
@@ -310,12 +332,12 @@ foo_lib = shared_library('foo', 'foo.vala',
                   install_dir: [true, true, true, true])
 ```
 
-The `true` value in `install_dir` tells Meson to use the default directory (i.e.
+The `true` value in `install_dir` tells Meson to use the default
-`share/gir-1.0` for GIRs). The fourth element in the `install_dir` array
+directory (i.e. `share/gir-1.0` for GIRs). The fourth element in the
-indicates where the GIR file will be installed.
+`install_dir` array indicates where the GIR file will be installed.
 
-To then generate a typelib file use a custom target with the `g-ir-compiler`
+To then generate a typelib file use a custom target with the
-program and a dependency on the library:
+`g-ir-compiler` program and a dependency on the library:
 
 ```meson
 g_ir_compiler = find_program('g-ir-compiler')

docs/markdown/Windows-module.md

@@ -7,10 +7,10 @@ Windows.
 
 ### compile_resources
 
-Compiles Windows `rc` files specified in the positional
+Compiles Windows `rc` files specified in the positional arguments.
-arguments. Returns an opaque object that you put in the list of
+Returns an opaque object that you put in the list of sources for the
-sources for the target you want to have the resources in. This method
+target you want to have the resources in. This method has the
-has the following keyword argument.
+following keyword argument.
 
 - `args` lists extra arguments to pass to the resource compiler
 - `depend_files` lists resource files that the resource script depends on

docs/markdown/Wrap-best-practices-and-tips.md

@@ -43,9 +43,9 @@ internal_inc = include_directories('.') # At top level meson.build
 
 Some platforms (e.g. iOS) requires linking everything in your main app
 statically. In other cases you might want shared libraries. They are
-also faster during development due to Meson's relinking
+also faster during development due to Meson's relinking optimization.
-optimization. However building both library types on all builds is
+However building both library types on all builds is slow and
-slow and wasteful.
+wasteful.
 
 Your project should use the `library` method that can be toggled
 between shared and static with the `default_library` builtin option.
@@ -139,21 +139,20 @@ quickly run afoul of the [One Definition Rule
 (ODR)](https://en.wikipedia.org/wiki/One_Definition_Rule) in C++, as
 you have more than one definition of a symbol, yielding undefined
 behavior. While C does not have a strict ODR rule, there is no
-language in the standard which guarantees such behavior to
+language in the standard which guarantees such behavior to work.
-work. Violations of the ODR can lead to weird idiosyncratic failures
+Violations of the ODR can lead to weird idiosyncratic failures such as
-such as segfaults. In the overwhelming number of cases, exposing
+segfaults. In the overwhelming number of cases, exposing library
-library sources via the `sources` argument in `declare_dependency` is
+sources via the `sources` argument in `declare_dependency` is thus
-thus incorrect. If you wish to get full cross-library performance,
+incorrect. If you wish to get full cross-library performance, consider
-consider building `mysupportlib` as a static library instead and
+building `mysupportlib` as a static library instead and employing LTO.
-employing LTO.
 
 There are exceptions to this rule. If there are some natural
-constraints on how your library is to be used, you can expose
+constraints on how your library is to be used, you can expose sources.
-sources. For instance, the WrapDB module for GoogleTest directly
+For instance, the WrapDB module for GoogleTest directly exposes the
-exposes the sources of GTest and GMock. This is valid, as GTest and
+sources of GTest and GMock. This is valid, as GTest and GMock will
-GMock will only ever be used in *terminal* link targets. A terminal
+only ever be used in *terminal* link targets. A terminal target is the
-target is the final target in a dependency link chain, for instance
+final target in a dependency link chain, for instance `myexe` in the
-`myexe` in the last example, whereas `mylibrary` is an intermediate
+last example, whereas `mylibrary` is an intermediate link target. For
-link target. For most libraries this rule is not applicable though, as
+most libraries this rule is not applicable though, as you cannot in
-you cannot in general control how others consume your library, and as
+general control how others consume your library, and as such should
-such should not expose sources.
+not expose sources.

docs/markdown/Wrap-dependency-system-manual.md

@@ -30,12 +30,13 @@ static library).
 To use this kind of a project as a dependency you could just copy and
 extract it inside your project's `subprojects` directory.
 
-However there is a simpler way. You can specify a Wrap file that tells Meson
+However there is a simpler way. You can specify a Wrap file that tells
-how to download it for you. If you then use this subproject in your build,
+Meson how to download it for you. If you then use this subproject in
-Meson will automatically download and extract it during build. This makes
+your build, Meson will automatically download and extract it during
-subproject embedding extremely easy.
+build. This makes subproject embedding extremely easy.
 
-All wrap files must have a name of `<project_name>.wrap` form and be in `subprojects` dir.
+All wrap files must have a name of `<project_name>.wrap` form and be
+in `subprojects` dir.
 
 Currently Meson has four kinds of wraps:
 - wrap-file
@@ -45,10 +46,11 @@ Currently Meson has four kinds of wraps:
 
 ## wrap format
 
-Wrap files are written in ini format, with a single header containing the type
+Wrap files are written in ini format, with a single header containing
-of wrap, followed by properties describing how to obtain the sources, validate
+the type of wrap, followed by properties describing how to obtain the
-them, and modify them if needed. An example wrap-file for the wrap named
+sources, validate them, and modify them if needed. An example
-`libfoobar` would have a filename `libfoobar.wrap` and would look like this:
+wrap-file for the wrap named `libfoobar` would have a filename
+`libfoobar.wrap` and would look like this:
 
 ```ini
 [wrap-file]
@@ -68,9 +70,12 @@ revision = head
 ```
 
 ## Accepted configuration properties for wraps
-- `directory` - name of the subproject root directory, defaults to the name of the wrap.
 
-Since *0.55.0* those can be used in all wrap types, they were previously reserved to `wrap-file`:
+- `directory` - name of the subproject root directory, defaults to the
+  name of the wrap.
+
+Since *0.55.0* those can be used in all wrap types, they were
+previously reserved to `wrap-file`:
 
 - `patch_url` - download url to retrieve an optional overlay archive
 - `patch_fallback_url` - fallback URL to be used when download from `patch_url` fails *Since: 0.55.0*
@@ -90,9 +95,10 @@ Since *0.55.0* those can be used in all wrap types, they were previously reserve
   directory.
 
 Since *0.55.0* it is possible to use only the `source_filename` and
-`patch_filename` value in a .wrap file (without `source_url` and `patch_url`) to
+`patch_filename` value in a .wrap file (without `source_url` and
-specify a local archive in the `subprojects/packagefiles` directory. The `*_hash`
+`patch_url`) to specify a local archive in the
-entries are optional when using this method. This method should be preferred over
+`subprojects/packagefiles` directory. The `*_hash` entries are
+optional when using this method. This method should be preferred over
 the old `packagecache` approach described below.
 
 Since *0.49.0* if `source_filename` or `patch_filename` is found in the
@@ -136,16 +142,17 @@ thousands of lines of code. Once you have a working build definition,
 just zip up the Meson build files (and others you have changed) and
 put them somewhere where you can download them.
 
-Prior to *0.55.0* Meson build patches were only supported for wrap-file mode.
+Prior to *0.55.0* Meson build patches were only supported for
-When using wrap-git, the repository must contain all Meson build definitions.
+wrap-file mode. When using wrap-git, the repository must contain all
-Since *0.55.0* Meson build patches are supported for any wrap modes, including
+Meson build definitions. Since *0.55.0* Meson build patches are
-wrap-git.
+supported for any wrap modes, including wrap-git.
 
 ## `provide` section
 
 *Since *0.55.0*
 
-Wrap files can define the dependencies it provides in the `[provide]` section.
+Wrap files can define the dependencies it provides in the `[provide]`
+section.
 
 ```ini
 [provide]
@@ -177,27 +184,31 @@ if not foo_dep.found()
 endif
 ```
 
-- Sometimes not-found dependency is preferable to a fallback when the feature is
+- Sometimes not-found dependency is preferable to a fallback when the
-  not explicitly requested by the user. In that case
+  feature is not explicitly requested by the user. In that case
-  `dependency('foo-1.0', required: get_option('foo_opt'))` will only fallback
+  `dependency('foo-1.0', required: get_option('foo_opt'))` will only
-  when the user sets `foo_opt` to `enabled` instead of `auto`.
+  fallback when the user sets `foo_opt` to `enabled` instead of
-
+  `auto`.
-If it is desired to fallback for an optional dependency, the `fallback`
+
-or `allow_fallback` keyword arguments must be passed explicitly. *Since
+If it is desired to fallback for an optional dependency, the
-0.56.0*, `dependency('foo-1.0', required: get_option('foo_opt'),
+`fallback` or `allow_fallback` keyword arguments must be passed
-allow_fallback: true)` will use the fallback even when `foo_opt` is set
+explicitly. *Since 0.56.0*, `dependency('foo-1.0', required:
-to `auto`.  On version *0.55.0* the same effect could be achieved with
+get_option('foo_opt'), allow_fallback: true)` will use the fallback
-`dependency('foo-1.0', required: get_option('foo_opt'), fallback: 'foo')`.
+even when `foo_opt` is set to `auto`. On version *0.55.0* the same
-
+effect could be achieved with `dependency('foo-1.0', required:
-This mechanism assumes the subproject calls `meson.override_dependency('foo-1.0', foo_dep)`
+get_option('foo_opt'), fallback: 'foo')`.
-so Meson knows which dependency object should be used as fallback. Since that
+
-method was introduced in version *0.54.0*, as a transitional aid for projects
+This mechanism assumes the subproject calls
-that do not yet make use of it the variable name can be provided in the wrap file
+`meson.override_dependency('foo-1.0', foo_dep)` so Meson knows which
-with entries in the format `foo-1.0 = foo_dep`.
+dependency object should be used as fallback. Since that method was
+introduced in version *0.54.0*, as a transitional aid for projects
+that do not yet make use of it the variable name can be provided in
+the wrap file with entries in the format `foo-1.0 = foo_dep`.
 
 For example when using a recent enough version of glib that uses
-`meson.override_dependency()` to override `glib-2.0`, `gobject-2.0` and `gio-2.0`,
+`meson.override_dependency()` to override `glib-2.0`, `gobject-2.0`
-a wrap file would look like:
+and `gio-2.0`, a wrap file would look like:
+
 ```ini
 [wrap-git]
 url=https://gitlab.gnome.org/GNOME/glib.git
@@ -207,7 +218,9 @@ revision=glib-2-62
 dependency_names = glib-2.0, gobject-2.0, gio-2.0
 ```
 
-With older version of glib dependency variable names need to be specified:
+With older version of glib dependency variable names need to be
+specified:
+
 ```ini
 [wrap-git]
 url=https://gitlab.gnome.org/GNOME/glib.git
@@ -219,25 +232,32 @@ gobject-2.0=gobject_dep
 gio-2.0=gio_dep
 ```
 
-Programs can also be provided by wrap files, with the `program_names` key:
+Programs can also be provided by wrap files, with the `program_names`
+key:
+
 ```ini
 [provide]
 program_names = myprog, otherprog
 ```
 
-With such wrap file, `find_program('myprog')` will automatically fallback to use
+With such wrap file, `find_program('myprog')` will automatically
-the subproject, assuming it uses `meson.override_find_program('myprog')`.
+fallback to use the subproject, assuming it uses
+`meson.override_find_program('myprog')`.
 
 ## Using wrapped projects
 
-Wraps provide a convenient way of obtaining a project into your subproject directory.
+Wraps provide a convenient way of obtaining a project into your
-Then you use it as a regular subproject (see [subprojects](Subprojects.md)).
+subproject directory. Then you use it as a regular subproject (see
+[subprojects](Subprojects.md)).
 
 ## Getting wraps
 
 Usually you don't want to write your wraps by hand.
 
-There is an online repository called [WrapDB](https://wrapdb.mesonbuild.com) that provides
+There is an online repository called
-many dependencies ready to use. You can read more about WrapDB [here](Using-the-WrapDB.md).
+[WrapDB](https://wrapdb.mesonbuild.com) that provides many
+dependencies ready to use. You can read more about WrapDB
+[here](Using-the-WrapDB.md).
 
-There is also a Meson subcommand to get and manage wraps (see [using wraptool](Using-wraptool.md)).
+There is also a Meson subcommand to get and manage wraps (see [using
+wraptool](Using-wraptool.md)).

docs/markdown/Wrap-review-guidelines.md

@@ -9,14 +9,15 @@ guarantee that the package will get accepted. Use common sense.
 
 ## Setting up the tools
 
-The [mesonwrap repository](https://github.com/mesonbuild/mesonwrap) provides tools
+The [mesonwrap repository](https://github.com/mesonbuild/mesonwrap)
-to maintain the WrapDB. Read-only features such can be used by anyone without Meson admin rights.
+provides tools to maintain the WrapDB. Read-only features such can be
+used by anyone without Meson admin rights.
 
 ## Personal access token
 
-Some tools require access to the Github API.
+Some tools require access to the Github API. A [personal access
-A [personal access token](https://github.com/settings/tokens) may be required
+token](https://github.com/settings/tokens) may be required if the
-if the freebie Github API quota is exhausted. `public_repo` scope is required
+freebie Github API quota is exhausted. `public_repo` scope is required
 for write operations.
 
 ```
@@ -31,7 +32,8 @@ github_token = <github token>
 mesonwrap review zlib --pull-request=1 [--approve]
 ```
 
-Since not every check can be automated please pay attention to the following during the review:
+Since not every check can be automated please pay attention to the
+following during the review:
 
 - Download link points to an authoritative upstream location.
 - Version branch is created from master.

docs/markdown/fallback-wraptool.md

@@ -22,8 +22,8 @@ To install a wrap, go to your source root, make sure that the
 This will stage the subproject ready to use. If you have multiple
 subprojects you need to download them all manually.
 
-Specifying branch name is optional. If not specified, the list
+Specifying branch name is optional. If not specified, the list of
-of potential branches is sorted alphabetically and the last branch is 
+potential branches is sorted alphabetically and the last branch is
 used.
 
 *Note* The tool was added in 0.32.0, for versions older than that you

docs/markdown/howtox.md

@@ -12,35 +12,41 @@ When first running Meson, set it in an environment variable.
 $ CC=mycc meson <options>
 ```
 
-Note that environment variables like `CC` only works in native builds. The `CC`
+Note that environment variables like `CC` only works in native builds.
-refers to the compiler for the host platform, that is the compiler used to
+The `CC` refers to the compiler for the host platform, that is the
-compile programs that run on the machine we will eventually install the project
+compiler used to compile programs that run on the machine we will
-on. The compiler used to build things that run on the machine we do the
+eventually install the project on. The compiler used to build things
-building can be specified with `CC_FOR_BUILD`. You can use it in cross builds.
+that run on the machine we do the building can be specified with
+`CC_FOR_BUILD`. You can use it in cross builds.
 
-Note that environment variables are never the idiomatic way to do anything with
+Note that environment variables are never the idiomatic way to do
-Meson, however. It is better to use the native and cross files. And the tools
+anything with Meson, however. It is better to use the native and cross
-for the host platform in cross builds can only be specified with a cross file.
+files. And the tools for the host platform in cross builds can only be
+specified with a cross file.
 
-There is a table of all environment variables supported [Here](Reference-tables.md#compiler-and-linker-selection-variables)
+There is a table of all environment variables supported
+[Here](Reference-tables.md#compiler-and-linker-selection-variables)
 
 
 ## Set linker
 
 *New in 0.53.0*
 
-Like the compiler, the linker is selected via the `<compiler variable>_LD`
+Like the compiler, the linker is selected via the `<compiler
-environment variable, or through the `<compiler entry>_ld` entry in a native
+variable>_LD` environment variable, or through the `<compiler
-or cross file. You must be aware of whether you're using a compiler that
+entry>_ld` entry in a native or cross file. You must be aware of
-invokes the linker itself (most compilers including GCC and Clang) or a
+whether you're using a compiler that invokes the linker itself (most
-linker that is invoked directly (when using MSVC or compilers that act like
+compilers including GCC and Clang) or a linker that is invoked
-it, including Clang-Cl). With the former `c_ld` or `CC_LD` should be the value
+directly (when using MSVC or compilers that act like it, including
-to pass to the compiler's special argument (such as `-fuse-ld` with clang and
+Clang-Cl). With the former `c_ld` or `CC_LD` should be the value to
-gcc), with the latter it should be an executable, such as `lld-link.exe`.
+pass to the compiler's special argument (such as `-fuse-ld` with clang
-
+and gcc), with the latter it should be an executable, such as
-*NOTE* In meson 0.53.0 the `ld` entry in the cross/native file and the `LD`
+`lld-link.exe`.
-environment variable were used, this resulted in a large number of regressions
+
-and was changed in 0.53.1 to `<lang>_ld` and `<comp variable>_LD`.
+*NOTE* In meson 0.53.0 the `ld` entry in the cross/native file and the
+`LD` environment variable were used, this resulted in a large number
+of regressions and was changed in 0.53.1 to `<lang>_ld` and `<comp
+variable>_LD`.
 
 ```console
 $ CC=clang CC_LD=lld meson <options>
@@ -60,7 +66,8 @@ c = 'clang'
 c_ld = 'lld'
 ```
 
-There is a table of all environment variables supported [Here](Reference-tables.md#compiler-and-linker-selection-variables)
+There is a table of all environment variables supported
+[Here](Reference-tables.md#compiler-and-linker-selection-variables)
 
 
 ## Set default C/C++ language version
@@ -90,8 +97,8 @@ executable(..., dependencies : thread_dep)
 ## Set extra compiler and linker flags from the outside (when e.g. building distro packages)
 
 The behavior is the same as with other build systems, with environment
-variables during first invocation. Do not use these when you need to rebuild
+variables during first invocation. Do not use these when you need to
-the source
+rebuild the source
 
 ```console
 $ CFLAGS=-fsomething LDFLAGS=-Wl,--linker-flag meson <options>
@@ -245,9 +252,10 @@ executable(..., install : true, install_dir : get_option('libexecdir'))
 
 ## Use existing `Find<name>.cmake` files
 
-Meson can use the CMake `find_package()` ecosystem if CMake is installed.
+Meson can use the CMake `find_package()` ecosystem if CMake is
-To find a dependency with custom `Find<name>.cmake`, set the `cmake_module_path`
+installed. To find a dependency with custom `Find<name>.cmake`, set
-property to the path in your project where the CMake scripts are stored.
+the `cmake_module_path` property to the path in your project where the
+CMake scripts are stored.
 
 Example for a `FindCmakeOnlyDep.cmake` in a `cmake` subdirectory: