Rewrap long text lines in docs. [skip ci]docrewrap

1 files changed, 155 insertions, 127 deletions

diff --git a/docs/markdown/Release-notes-for-0.54.0.md b/docs/markdown/Release-notes-for-0.54.0.md
index 0807d2e..103d103 100644
--- a/docs/markdown/Release-notes-for-0.54.0.md
+++ b/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
-builtin has been added to control the PTHREAD_POOL_SIZE option,
-`-D<lang>_thread_count`, which may be set to any integer value greater than 0.
-If it set to 0 then the PTHREAD_POOL_SIZE option will not be passed.
+In addition to properly setting the compile and linker arguments, a
+new meson builtin has been added to control the PTHREAD_POOL_SIZE
+option, `-D<lang>_thread_count`, which may be set to any integer value
+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
-reported relative to the current working directory (when possible), or as
-absolute paths (when a relative path does not exist, e.g. a Windows path
-starting with a different drive letter to the current working directory).
+The paths for filenames in error and warning locations are now
+consistently reported relative to the current working directory (when
+possible), or as absolute paths (when a relative path does not exist,
+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
-warnings and most errors, and relative to cwd for certain parser errors)
+(The previous behaviour was to report a path relative to the source
+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
-value is now cached. Any subsequent call will return the same value as long as
-version requested match, otherwise not-found dependency is returned. This means
-that if a system dependency is first found, it won't fallback to a subproject
-in a subsequent call any more and will rather return not-found instead if the
-system version does not match. Similarly, if the first call returns the subproject
-fallback dependency, it will also return the subproject dependency in a subsequent
-call even if no fallback is provided.
+The first time a dependency is found, using `dependency('foo', ...)`,
+the return value is now cached. Any subsequent call will return the
+same value as long as version requested match, otherwise not-found
+dependency is returned. This means that if a system dependency is
+first found, it won't fallback to a subproject in a subsequent call
+any more and will rather return not-found instead if the system
+version does not match. Similarly, if the first call returns the
+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
-every subproject from there on.
+to any dependency object you want. The overriding is global and
+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
-to the override `bar_dep` is now set to the subproject's version instead.
+This used to mix system 1.0 version and subproject 2.0 dependencies,
+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.
-If the subproject does `dependency('foo')` but the main project wants to provide
-its own implementation of `foo`, it can for example call
-`meson.override_dependency('foo', declare_dependency(...))` before configuring the
-subproject.
+Another case this can be useful is to force a subproject to use a
+specific dependency. If the subproject does `dependency('foo')` but
+the main project wants to provide its own implementation of `foo`, it
+can for example call `meson.override_dependency('foo',
+declare_dependency(...))` before configuring the subproject.
 
 ## Simplified `dependency()` fallback
 
-In the case a subproject `foo` calls `meson.override_dependency('foo-2.0', foo_dep)`,
-the parent project can omit the dependency variable name in fallback keyword
-argument: `dependency('foo-2.0', fallback : 'foo')`.
+In the case a subproject `foo` calls
+`meson.override_dependency('foo-2.0', foo_dep)`, the parent project
+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
-compilation. It accepts two arguments, `-j` and `-l`, which are used if
-possible (`-l` does nothing with msbuild). A `-j` or `-l` value < 1 lets the
-backend decide how many threads to use. For msbuild this means `-m`, for
-ninja it means passing no arguments.
+A new `meson compile` command has been added to support backend
+agnostic compilation. It accepts two arguments, `-j` and `-l`, which
+are used if possible (`-l` does nothing with msbuild). A `-j` or `-l`
+value < 1 lets the backend decide how many threads to use. For msbuild
+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
-`native: true` targets, without breaking backwards compatibility for build
-definitions which assume that the native compiler is available after
-`add_languages()`, if the `native:` keyword is absent the languages may be used
-for either the build or host machine, but are never required for the build
-machine.
+For the benefit of existing simple build definitions which don't
+contain any `native: true` targets, without breaking backwards
+compatibility for build definitions which assume that the native
+compiler is available after `add_languages()`, if the `native:`
+keyword is absent the languages may be used for either the build or
+host machine, but are never required for the build machine.
 
-This changes the behaviour of the following meson fragment (when cross-compiling
-but a native compiler is not available) from reporting an error at
-`add_language` to reporting an error at `executable`.
+This changes the behaviour of the following meson fragment (when
+cross-compiling but a native compiler is not available) from reporting
+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.
-If defined and the value is a list, elements will be separated by the provided
-string instead of being aligned on a new line.
+A new `list_sep` keyword argument has been added to `summary()`
+function. If defined and the value is a list, elements will be
+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
-during that subproject configuration, or the error message if the configuration failed.
+The automatic `subprojects` section now also print the number of
+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
-pkg-config or cmake, neither of which are part of the base install on those
-OSes (but zlib is).
+This allows zlib to be detected on macOS and FreeBSD without the use
+of pkg-config or cmake, neither of which are part of the base install
+on those OSes (but zlib is).
 
-A side effect of this change is that `dependency('zlib')` also works with
-cmake instead of requiring `dependency('ZLIB')`.
+A side effect of this change is that `dependency('zlib')` also works
+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
-every file as it is being installed. As before, the full log is always
-available inside the builddir in `meson-logs/install-log.txt`.
+Now you can run `meson install --quiet` and meson will not verbosely
+print every file as it is being installed. As before, the full log is
+always available inside the builddir in `meson-logs/install-log.txt`.
 
-When this option is passed, install scripts will have the environment variable
-`MESON_INSTALL_QUIET` set.
+When this option is passed, install scripts will have the environment
+variable `MESON_INSTALL_QUIET` set.
 
-Numerous speed-ups were also made for the install step, especially on Windows
-where it is now 300% to 1200% faster than before depending on your workload.
+Numerous speed-ups were also made for the install step, especially on
+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
-really true. It does have a linker, called wasm-ld (meson's name is ld.wasm).
-This is a special version of clang's lld. This will now be detected properly.
+Before 0.54.0 we treated emscripten as both compiler and linker, which
+isn't really true. It does have a linker, called wasm-ld (meson's name
+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
-variable (or d_ld in the cross file) and is able to pick different linkers.
+LDC (the llvm D compiler) and GDC (The Gnu D Compiler) now honor D_LD
+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,
-ld.lld, ld64, link, and lld-link.
+GDC supports all of the same values as GCC, LDC supports ld.bfd,
+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.
-The `properties` are new for Meson 0.54.0, and are read like:
+which are defined and used the same way as in cross files. The
+`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
-allowing the signal to be handled. However, it is now the responsibility of
-the custom signal handler (if any) to ensure that any process spawned by the
-top-level test processes is correctly killed.
+A test process (group) is now terminated via SIGTERM instead of
+SIGKILL allowing the signal to be handled. However, it is now the
+responsibility of the custom signal handler (if any) to ensure that
+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
-should be `${COMPILER_VAR}_LD`, but that's only the case for about half of
-the variables. The other half are different. In 0.54.0 the variables match.
-The old variables are still supported, but are deprecated and raise a
-deprecation warning.
+The docs have always claimed that the Dynamic Linker environment
+variable should be `${COMPILER_VAR}_LD`, but that's only the case for
+about half of the variables. The other half are different. In 0.54.0
+the variables match. The old variables are still supported, but are
+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.
-This is useful for example when building shared libraries in the main project,
-but static link a subproject, or when the main project must build with no warnings
-but some subprojects cannot.
+The `default_library` and `werror` built-in options can now be defined
+per subproject. This is useful for example when building shared
+libraries in the main project, but static link a subproject, or 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
-subproject's default_options (e.g. `subproject('foo', default_options: 'default_library=static')`),
-or by the user using the command line `-Dfoo:default_library=static`.
+Most of the time this would be used either by the parent project by
+setting subproject's default_options (e.g. `subproject('foo',
+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
-platforms for native builds, but the just the build platform for cross builds.
-Now `CC_FOR_BUILD` is used for the build platform in cross builds.
+Previously in Meson, variables like `CC` effected both the host and
+build platforms for native builds, but the just the build platform for
+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
-quite the same, but doesn't conflict: meson doesn't always repond to an
-environment when Autoconf would, but when it does it interprets it as Autotools
-would.
+environment variables are supported at all in Meson. The new behavior
+is not quite the same, but doesn't conflict: meson doesn't always
+repond to an environment when Autoconf would, but when it does it
+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`,
-`Cuda`, `Objective-C++`, and `C#`, we provided with associated
-values for corresponding languages, available for both library,
-and executable.
+Meson now ships with predefined project templates for `Java`, `Cuda`,
+`Objective-C++`, and `C#`, we provided with associated values for
+corresponding languages, available for both library, and executable.
 
 ## Ninja version requirement bumped to 1.7
 
-Meson now uses the [Implicit outputs](https://ninja-build.org/manual.html#ref_outputs)
-feature of Ninja for some types of targets that have multiple outputs which may
+Meson now uses the [Implicit
+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)
-(the oldest Ubuntu LTS at the time of writing) is 1.7.1. If your 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
+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)
+(the oldest Ubuntu LTS at the time of writing) is 1.7.1. If your
+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
-root directory. If this isn't the case, you can now use
-`-C` to specify the actual project source directory.
+The meson init assumes that it is run inside the project root
+directory. If this isn't the case, you can now use `-C` to specify the
+actual project source directory.
 
 ## More than one argument to `message()` and `warning()`
 
-Arguments passed to `message()` and `warning()` will be printed separated by
-space.
+Arguments passed to `message()` and `warning()` will be printed
+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
-`foo.pc` file, an extra `foo-uninstalled.pc` file is placed into
-`<builddir>/meson-uninstalled`. They can be used to build applications against
-libraries built by meson without installing them, by pointing `PKG_CONFIG_PATH`
-to that directory. This is an experimental feature provided on a best-effort
-basis, it might not work in all use-cases.
+The `pkgconfig` module now generates uninstalled pc files as well. For
+any generated `foo.pc` file, an extra `foo-uninstalled.pc` file is
+placed into `<builddir>/meson-uninstalled`. They can be used to build
+applications against libraries built by meson without installing them,
+by pointing `PKG_CONFIG_PATH` to that directory. This is an
+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
-new `components` kwarg in the `dependency` function.
+It is now possible to pass components to the CMake dependency backend
+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
-more verbose compilation logs. Note that for VS backend it means that logs will
-be less verbose by default (without `--verbose` option).
+The new option `--verbose` has been added to `meson compile` that will
+enable more verbose compilation logs. Note that for VS backend it
+means that logs will be less verbose by default (without `--verbose`
+option).