Generate release notes for 1.3.0.

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

@@ -0,0 +1,338 @@
+---
+title: Release 1.3.0
+short-description: Release notes for 1.3.0
+...
+
+# New features
+
+Meson 1.3.0 was released on 19 November 2023
+## Clarify of implicitly-included headers in C-like compiler checks
+
+Compiler check methods `compiler.compute_int()`, `compiler.alignment()`
+and `compiler.sizeof()` now have their implicitly-included headers
+corrected and documented.
+
+`<stdio.h>` was included unintentionally when cross-compiling, which
+is less than ideal because there is no guarantee that a standard library
+is available for the target platform. Only `<stddef.h>` is included instead.
+
+For projects that depend on the old behavior, the compiler check methods
+have an optional argument `prefix`, which can be used to specify additional
+`#include` directives.
+
+## Treat warnings as error in compiler checks
+
+Compiler check methods `compiler.compiles()`, `compiler.links()` and `compiler.run()`
+now have a new `werror: true` keyword argument to treat compiler warnings as error.
+This can be used to check if code compiles without warnings.
+
+## Compilers now have a `has_define` method
+
+This method returns true if the given preprocessor symbol is
+defined, else false is returned. This is useful is cases where
+an empty define has to be distinguished from a non-set one, which
+is not possible using `get_define`.
+
+Additionally it makes intent clearer for code that only needs
+to check if a specific define is set at all and does not care
+about its value.
+
+## [[configure_file]] now has a `macro_name` parameter.
+
+This new paramater, `macro_name` allows C macro-style include guards to be added
+to [[configure_file]]'s output when a template file is not given. This change
+simplifies the creation of configure files that define macros with dynamic names
+and want the C-style include guards.
+
+## `c_std` and `cpp_std` options now accepts a list of values
+
+Projects that prefer GNU C, but can fallback to ISO C, can now set, for
+example, `default_options: 'c_std=gnu11,c11'`, and it will use `gnu11` when
+available, but fallback to `c11` otherwise. It is an error only if none of the
+values are supported by the current compiler.
+
+Likewise, a project that can take benefit of `c++17` but can still build with
+`c++11` can set `default_options: 'cpp_std=c++17,c++11'`.
+
+This allows us to deprecate `gnuXX` values from the MSVC compiler. That means
+that `default_options: 'c_std=gnu11'` will now print a warning with MSVC
+but fallback to `c11`. No warning is printed if at least one
+of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
+
+In the future that deprecation warning will become an hard error because
+`c_std=gnu11` should mean GNU is required, for projects that cannot be
+built with MSVC for example.
+
+## More meaningful description of many generative tasks
+
+When a module uses a `CustomTarget` to process files, it now has the possibility
+to customize the message displayed by ninja.
+
+Many modules were updated to take advantage of this new feature.
+
+## Deprecate 'jar' as a build_target type
+
+The point of `build_target()` is that what is produced can be conditionally
+changed. However, `jar()` has a significant number of non-overlapping arguments
+from other build_targets, including the kinds of sources it can include. Because
+of this crafting a `build_target` that can be used as a Jar and as something
+else is incredibly hard to do. As such, it has been deprecated, and using
+`jar()` directly is recommended.
+
+## generator.process() gains 'env' keyword argument
+
+Like the kwarg of the same name in `custom_target()`, `env` allows
+you to set the environment in which the generator will process inputs.
+
+## Target names for executables now take into account suffixes.
+
+In previous versions of meson, a `meson.build` file like this:
+
+```
+exectuable('foo', 'main.c')
+exectuable('foo', 'main.c', name_suffix: 'bar')
+```
+
+would result in a configure error because meson internally used
+the same id for both executables. This build file is now allowed
+since meson takes into account the `bar` suffix when generating the
+second executable. This allows for executables with the same basename
+but different suffixes to be built in the same subdirectory.
+
+## Executable gains vs_module_defs keyword
+
+This allows using a .def file to control which functions an [[executable]] will
+expose to a [[shared_module]].
+
+## find_program() now supports the 'default_options' argument
+
+In a similar fashion as dependency(), find_program() now also allows you to set default 
+options for the subproject that gets built in case of a fallback.
+
+## `fs.relative_to()`
+
+The `fs` module now has a `relative_to` method. The method will return the
+relative path from argument one to argument two, if one exists. Otherwise, the
+absolute path to argument one is returned.
+
+```meson
+assert(fs.relative_to('c:\\prefix\\lib', 'c:\\prefix\\bin') == '..\\lib')
+assert(fs.relative_to('c:\\proj1\\foo', 'd:\\proj1\\bar') == 'c:\\proj1\\foo')
+assert(fs.relative_to('prefix\\lib\\foo', 'prefix') == 'lib\\foo')
+
+assert(fs.relative_to('/prefix/lib', '/prefix/bin') == '../lib')
+assert(fs.relative_to('prefix/lib/foo', 'prefix') == 'lib/foo')
+```
+
+In addition to strings, it can handle files, custom targets, custom target
+indices, and build targets.
+
+## Added follow_symlinks arg to install_data, install_header, and install_subdir
+
+The [[install_data]], [[install_headers]], [[install_subdir]] functions now
+have an optional argument `follow_symlinks` that, if set to `true`, makes it so
+symbolic links in the source are followed, rather than copied into the
+destination tree, to match the old behavior.  The default, which is currently
+to follow links, is subject to change in the future.
+
+## Added 'fill' kwarg to int.to_string()
+
+int.to_string() now accepts a `fill` argument. This allows you to pad the
+string representation of the integer with leading zeroes:
+
+```meson
+n = 4
+message(n.to_string())
+message(n.to_string(fill: 3))
+
+n = -4
+message(n.to_string(fill: 3))
+```
+
+OUTPUT:
+```meson
+4
+004
+-04
+```
+
+## Added 'json' output_format to configure_file()
+
+When no input file is specified, [[configure_file]] can now
+generate a `json` file from given [[@cfg_data]]. 
+Field descriptions are not preserved in the json file.
+
+## `@GLOBAL_SOURCE_ROOT@` and `@DIRNAME@` in machine files
+
+Some tokens are now replaced in the machine file before parsing it:
+- `@GLOBAL_SOURCE_ROOT@`: the absolute path to the project's source tree
+- `@DIRNAME@`: the absolute path to the machine file's parent directory.
+
+It can be used, for example, to have paths relative to the source directory, or
+relative to toolchain's installation directory.
+```ini
+[binaries]
+c = '@DIRNAME@/toolchain/gcc'
+exe_wrapper = '@GLOBAL_SOURCE_ROOT@' / 'build-aux' / 'my-exe-wrapper.sh'
+```
+
+## clang-tidy-fix target
+
+If `clang-tidy` is installed and the project's source root contains a
+`.clang-tidy` (or `_clang-tidy`) file, Meson will automatically define
+a `clang-tidy-fix` target that runs `run-clang-tidy` tool with `-fix`
+option to apply the changes found by clang-tidy to the source code.
+
+If you have defined your own `clang-tidy-fix` target, Meson will not
+generate its own target.
+
+## Meson compile command now accepts suffixes for TARGET
+
+The syntax for specifying a target for meson compile is now
+`[PATH_TO_TARGET/]TARGET_NAME.TARGET_SUFFIX[:TARGET_TYPE]` where
+`TARGET_SUFFIX` is the suffix argument given in the build target
+within meson.build. It is optional and `TARGET_NAME` remains
+sufficient if it uniquely resolves to one single target.
+
+## New environment variable `MESON_PACKAGE_CACHE_DIR`
+
+If the `MESON_PACKAGE_CACHE_DIR` environment variable is set, it is used instead of the
+project's `subprojects/packagecache`. This allows sharing the cache across multiple
+projects. In addition it can contain an already extracted source tree as long as it
+has the same directory name as the `directory` field in the wrap file. In that
+case, the directory will be copied into `subprojects/` before applying patches.
+
+## Update options with `meson setup <builddir> -Dopt=value`
+
+If the build directory already exists, options are updated with their new value
+given on the command line (`-Dopt=value`). Unless `--reconfigure` is also specified,
+this won't reconfigure immediately. This has the same behaviour as
+`meson configure <builddir> -Dopt=value`.
+
+Previous Meson versions were simply a no-op.
+
+## Clear persistent cache with `meson setup --clearcache`
+
+Just like `meson configure --clearcache`, it is now possible to clear the cache
+and reconfigure in a single command with `meson setup --clearcache --reconfigure <builddir>`.
+
+## pkg-config dependencies can now get a variable with multiple replacements
+
+When using [[dep.get_variable]] and defining a `pkgconfig_define`, it is
+sometimes useful to remap multiple dependency variables. For example, if the
+upstream project changed the variable name that is interpolated and it is
+desirable to support both versions.
+
+It is now possible to pass multiple pairs of variable/value.
+
+The same applies to the compatibility [[dep.get_pkgconfig_variable]] method.
+
+## Machine files: `pkgconfig` field deprecated and replaced by `pkg-config`
+
+Meson used to allow both `pkgconfig` and `pkg-config` entries in machine files,
+the former was used for `dependency()` lookup and the latter was used as return
+value for `find_program('pkg-config')`.
+
+This inconsistency is now fixed by deprecating `pkgconfig` in favor of
+`pkg-config` which matches the name of the binary. For backward compatibility
+it is still allowed to define both with the same value, in that case no
+deprecation warning is printed.
+
+## Support targeting Python's limited C API
+
+The Python module's `extension_module` function has gained the ability
+to build extensions which target Python's limited C API via a new keyword
+argument: `limited_api`.
+
+## All compiler `has_*` methods support the `required` keyword
+
+Now instead of
+
+```meson
+assert(cc.has_function('some_function'))
+assert(cc.has_type('some_type'))
+assert(cc.has_member('struct some_type', 'x'))
+assert(cc.has_members('struct some_type', ['x', 'y']))
+```
+
+we can use
+
+```meson
+cc.has_function('some_function', required: true)
+cc.has_type('some_type', required: true)
+cc.has_member('struct some_type', 'x', required: true)
+cc.has_members('struct some_type', ['x', 'y'], required: true)
+```
+
+## Deprecated `rust_crate_type` and replaced by `rust_abi`
+
+The new `rust_abi` keyword argument is accepted by [[shared_library]],
+[[static_library]], [[library]] and [[shared_module]] functions. It can be either
+`'rust'` (the default) or `'c'` strings.
+
+`rust_crate_type` is now deprecated because Meson already knows if it's a shared
+or static library, user only need to specify the ABI (Rust or C).
+
+`proc_macro` crates are now handled by the [`rust.proc_macro()`](Rust-module.md#proc_macro)
+method.
+
+## Tests now abort on errors by default under sanitizers
+
+Sanitizers like AddressSanitizer and UndefinedBehaviorSanitizer do not abort
+by default on detected violations. Meson now exports `ASAN_OPTIONS` and `UBSAN_OPTIONS`
+when unset in the environment to provide sensible abort-by-default behavior.
+
+## `<lang>_(shared|static)_args` for both_library, library, and build_target
+
+We now allow passing arguments like `c_static_args` and `c_shared_args`. This
+allows a [[both_libraries]] to have arguments specific to either the shared or
+static library, as well as common arguments to both.
+
+There is a drawback to this, since Meson now cannot re-use object files between
+the static and shared targets. This could lead to much higher compilation time
+when using a [[both_libraries]] if there are many sources.
+
+## `-j` shorthand for `--num-processes`
+
+`-j` now means the same thing as `--num-processes`. It was inconsistently
+supported only in some subcommands. Now you may use it everywhere
+
+## Unified message(), str.format() and f-string formatting
+
+They now all support the same set of values: strings, integers, bools, options,
+dictionaries and lists thereof.
+
+- Feature options (i.e. enabled, disabled, auto) were not previously supported
+  by any of those functions.
+- Lists and dictionaries were not previously supported by f-string.
+- str.format() allowed any type and often resulted in printing the internal
+  representation which is now deprecated.
+
+## Subprojects excluded from scan-build reports
+
+The `scan-build` target, created when using the `ninja` backend with `scan-build`
+present, now excludes bugs found in subprojects from its final report.
+
+## vs_module_defs keyword now supports indexes of custom_target
+
+This means you can do something like:
+```meson
+defs = custom_target('generate_module_defs', ...)
+shared_library('lib1', vs_module_defs : defs[0])
+shared_library('lib2', vs_module_defs : defs[2])
+```
+
+## Automatic fallback to `cmake` and `cargo` subproject
+
+CMake subprojects have been supported for a while using the `cmake.subproject()`
+module method. However until now it was not possible to use a CMake subproject
+as fallback in a `dependency()` call.
+
+A wrap file can now specify the method used to build it by setting the `method`
+key in the wrap file's first section. The method defaults to `meson`.
+
+Supported methods:
+- `meson` requires `meson.build` file.
+- `cmake` requires `CMakeLists.txt` file. [See details](Wrap-dependency-system-manual.md#cmake-wraps).
+- `cargo` requires `Cargo.toml` file. [See details](Wrap-dependency-system-manual.md#cargo-wraps).
+

docs/markdown/snippets/clike_compilers_implicit_includes.md

@@ -1,13 +0,0 @@
-## Clarify of implicitly-included headers in C-like compiler checks
-
-Compiler check methods `compiler.compute_int()`, `compiler.alignment()`
-and `compiler.sizeof()` now have their implicitly-included headers
-corrected and documented.
-
-`<stdio.h>` was included unintentionally when cross-compiling, which
-is less than ideal because there is no guarantee that a standard library
-is available for the target platform. Only `<stddef.h>` is included instead.
-
-For projects that depend on the old behavior, the compiler check methods
-have an optional argument `prefix`, which can be used to specify additional
-`#include` directives.

docs/markdown/snippets/compile_werror.md

@@ -1,5 +0,0 @@
-## Treat warnings as error in compiler checks
-
-Compiler check methods `compiler.compiles()`, `compiler.links()` and `compiler.run()`
-now have a new `werror: true` keyword argument to treat compiler warnings as error.
-This can be used to check if code compiles without warnings.

docs/markdown/snippets/compiler_has_define.md

@@ -1,10 +0,0 @@
-## Compilers now have a `has_define` method
-
-This method returns true if the given preprocessor symbol is
-defined, else false is returned. This is useful is cases where
-an empty define has to be distinguished from a non-set one, which
-is not possible using `get_define`.
-
-Additionally it makes intent clearer for code that only needs
-to check if a specific define is set at all and does not care
-about its value.

docs/markdown/snippets/configure_file_macro_guard.md

@@ -1,6 +0,0 @@
-## [[configure_file]] now has a `macro_name` parameter.
-
-This new paramater, `macro_name` allows C macro-style include guards to be added
-to [[configure_file]]'s output when a template file is not given. This change
-simplifies the creation of configure files that define macros with dynamic names
-and want the C-style include guards.

docs/markdown/snippets/cstd.md

@@ -1,18 +0,0 @@
-## `c_std` and `cpp_std` options now accepts a list of values
-
-Projects that prefer GNU C, but can fallback to ISO C, can now set, for
-example, `default_options: 'c_std=gnu11,c11'`, and it will use `gnu11` when
-available, but fallback to `c11` otherwise. It is an error only if none of the
-values are supported by the current compiler.
-
-Likewise, a project that can take benefit of `c++17` but can still build with
-`c++11` can set `default_options: 'cpp_std=c++17,c++11'`.
-
-This allows us to deprecate `gnuXX` values from the MSVC compiler. That means
-that `default_options: 'c_std=gnu11'` will now print a warning with MSVC
-but fallback to `c11`. No warning is printed if at least one
-of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
-
-In the future that deprecation warning will become an hard error because
-`c_std=gnu11` should mean GNU is required, for projects that cannot be
-built with MSVC for example.

docs/markdown/snippets/custom_target_description.md

@@ -1,6 +0,0 @@
-## More meaningful description of many generative tasks
-
-When a module uses a `CustomTarget` to process files, it now has the possibility
-to customize the message displayed by ninja.
-
-Many modules were updated to take advantage of this new feature.

docs/markdown/snippets/deprecate_build_target_jar.md

@@ -1,8 +0,0 @@
-## Deprecate 'jar' as a build_target type
-
-The point of `build_target()` is that what is produced can be conditionally
-changed. However, `jar()` has a significant number of non-overlapping arguments
-from other build_targets, including the kinds of sources it can include. Because
-of this crafting a `build_target` that can be used as a Jar and as something
-else is incredibly hard to do. As such, it has been deprecated, and using
-`jar()` directly is recommended.

docs/markdown/snippets/env_kwarg_generator_process.md

@@ -1,4 +0,0 @@
-## generator.process() gains 'env' keyword argument
-
-Like the kwarg of the same name in `custom_target()`, `env` allows
-you to set the environment in which the generator will process inputs.

docs/markdown/snippets/executable-suffixes.md

@@ -1,14 +0,0 @@
-## Target names for executables now take into account suffixes.
-
-In previous versions of meson, a `meson.build` file like this:
-
-```
-exectuable('foo', 'main.c')
-exectuable('foo', 'main.c', name_suffix: 'bar')
-```
-
-would result in a configure error because meson internally used
-the same id for both executables. This build file is now allowed
-since meson takes into account the `bar` suffix when generating the
-second executable. This allows for executables with the same basename
-but different suffixes to be built in the same subdirectory.

docs/markdown/snippets/executable_vs_module_defs.md

@@ -1,4 +0,0 @@
-## Executable gains vs_module_defs keyword
-
-This allows using a .def file to control which functions an [[executable]] will
-expose to a [[shared_module]].

docs/markdown/snippets/find_program_default_options.md

@@ -1,4 +0,0 @@
-## find_program() now supports the 'default_options' argument
-
-In a similar fashion as dependency(), find_program() now also allows you to set default 
-options for the subproject that gets built in case of a fallback.

docs/markdown/snippets/fs_relative_to.md

@@ -1,17 +0,0 @@
-## `fs.relative_to()`
-
-The `fs` module now has a `relative_to` method. The method will return the
-relative path from argument one to argument two, if one exists. Otherwise, the
-absolute path to argument one is returned.
-
-```meson
-assert(fs.relative_to('c:\\prefix\\lib', 'c:\\prefix\\bin') == '..\\lib')
-assert(fs.relative_to('c:\\proj1\\foo', 'd:\\proj1\\bar') == 'c:\\proj1\\foo')
-assert(fs.relative_to('prefix\\lib\\foo', 'prefix') == 'lib\\foo')
-
-assert(fs.relative_to('/prefix/lib', '/prefix/bin') == '../lib')
-assert(fs.relative_to('prefix/lib/foo', 'prefix') == 'lib/foo')
-```
-
-In addition to strings, it can handle files, custom targets, custom target
-indices, and build targets.

docs/markdown/snippets/install_follow_symlink_arg.md

@@ -1,7 +0,0 @@
-## Added follow_symlinks arg to install_data, install_header, and install_subdir
-
-The [[install_data]], [[install_headers]], [[install_subdir]] functions now
-have an optional argument `follow_symlinks` that, if set to `true`, makes it so
-symbolic links in the source are followed, rather than copied into the
-destination tree, to match the old behavior.  The default, which is currently
-to follow links, is subject to change in the future.

docs/markdown/snippets/int_to_string_fill.md

@@ -1,20 +0,0 @@
-## Added 'fill' kwarg to int.to_string()
-
-int.to_string() now accepts a `fill` argument. This allows you to pad the
-string representation of the integer with leading zeroes:
-
-```meson
-n = 4
-message(n.to_string())
-message(n.to_string(fill: 3))
-
-n = -4
-message(n.to_string(fill: 3))
-```
-
-OUTPUT:
-```meson
-4
-004
--04
-```

docs/markdown/snippets/json_output_format.md

@@ -1,5 +0,0 @@
-## Added 'json' output_format to configure_file()
-
-When no input file is specified, [[configure_file]] can now
-generate a `json` file from given [[@cfg_data]]. 
-Field descriptions are not preserved in the json file.

docs/markdown/snippets/machine_file_source_dir.md

@@ -1,13 +0,0 @@
-## `@GLOBAL_SOURCE_ROOT@` and `@DIRNAME@` in machine files
-
-Some tokens are now replaced in the machine file before parsing it:
-- `@GLOBAL_SOURCE_ROOT@`: the absolute path to the project's source tree
-- `@DIRNAME@`: the absolute path to the machine file's parent directory.
-
-It can be used, for example, to have paths relative to the source directory, or
-relative to toolchain's installation directory.
-```ini
-[binaries]
-c = '@DIRNAME@/toolchain/gcc'
-exe_wrapper = '@GLOBAL_SOURCE_ROOT@' / 'build-aux' / 'my-exe-wrapper.sh'
-```

docs/markdown/snippets/meson_clang_tidy_fix.md

@@ -1,9 +0,0 @@
-## clang-tidy-fix target
-
-If `clang-tidy` is installed and the project's source root contains a
-`.clang-tidy` (or `_clang-tidy`) file, Meson will automatically define
-a `clang-tidy-fix` target that runs `run-clang-tidy` tool with `-fix`
-option to apply the changes found by clang-tidy to the source code.
-
-If you have defined your own `clang-tidy-fix` target, Meson will not
-generate its own target.

docs/markdown/snippets/meson_compile_suffixes.md

@@ -1,7 +0,0 @@
-## Meson compile command now accepts suffixes for TARGET
-
-The syntax for specifying a target for meson compile is now
-`[PATH_TO_TARGET/]TARGET_NAME.TARGET_SUFFIX[:TARGET_TYPE]` where
-`TARGET_SUFFIX` is the suffix argument given in the build target
-within meson.build. It is optional and `TARGET_NAME` remains
-sufficient if it uniquely resolves to one single target.

docs/markdown/snippets/meson_home.md

@@ -1,7 +0,0 @@
-## New environment variable `MESON_PACKAGE_CACHE_DIR`
-
-If the `MESON_PACKAGE_CACHE_DIR` environment variable is set, it is used instead of the
-project's `subprojects/packagecache`. This allows sharing the cache across multiple
-projects. In addition it can contain an already extracted source tree as long as it
-has the same directory name as the `directory` field in the wrap file. In that
-case, the directory will be copied into `subprojects/` before applying patches.

docs/markdown/snippets/msetup.md

@@ -1,13 +0,0 @@
-## Update options with `meson setup <builddir> -Dopt=value`
-
-If the build directory already exists, options are updated with their new value
-given on the command line (`-Dopt=value`). Unless `--reconfigure` is also specified,
-this won't reconfigure immediately. This has the same behaviour as
-`meson configure <builddir> -Dopt=value`.
-
-Previous Meson versions were simply a no-op.
-
-## Clear persistent cache with `meson setup --clearcache`
-
-Just like `meson configure --clearcache`, it is now possible to clear the cache
-and reconfigure in a single command with `meson setup --clearcache --reconfigure <builddir>`.

docs/markdown/snippets/pkgconfig_define_variable.md

@@ -1,10 +0,0 @@
-## pkg-config dependencies can now get a variable with multiple replacements
-
-When using [[dep.get_variable]] and defining a `pkgconfig_define`, it is
-sometimes useful to remap multiple dependency variables. For example, if the
-upstream project changed the variable name that is interpolated and it is
-desirable to support both versions.
-
-It is now possible to pass multiple pairs of variable/value.
-
-The same applies to the compatibility [[dep.get_pkgconfig_variable]] method.

docs/markdown/snippets/pkgconfig_deprecated_machine_file.md

@@ -1,10 +0,0 @@
-## Machine files: `pkgconfig` field deprecated and replaced by `pkg-config`
-
-Meson used to allow both `pkgconfig` and `pkg-config` entries in machine files,
-the former was used for `dependency()` lookup and the latter was used as return
-value for `find_program('pkg-config')`.
-
-This inconsistency is now fixed by deprecating `pkgconfig` in favor of
-`pkg-config` which matches the name of the binary. For backward compatibility
-it is still allowed to define both with the same value, in that case no
-deprecation warning is printed.

docs/markdown/snippets/python_extension_module_limited_api.md

@@ -1,5 +0,0 @@
-## Support targeting Python's limited C API
-
-The Python module's `extension_module` function has gained the ability
-to build extensions which target Python's limited C API via a new keyword
-argument: `limited_api`.

docs/markdown/snippets/required_keyword_for_has_functions.md

@@ -1,19 +0,0 @@
-## All compiler `has_*` methods support the `required` keyword
-
-Now instead of
-
-```meson
-assert(cc.has_function('some_function'))
-assert(cc.has_type('some_type'))
-assert(cc.has_member('struct some_type', 'x'))
-assert(cc.has_members('struct some_type', ['x', 'y']))
-```
-
-we can use
-
-```meson
-cc.has_function('some_function', required: true)
-cc.has_type('some_type', required: true)
-cc.has_member('struct some_type', 'x', required: true)
-cc.has_members('struct some_type', ['x', 'y'], required: true)
-```

docs/markdown/snippets/rust_crate_type.md

@@ -1,11 +0,0 @@
-## Deprecated `rust_crate_type` and replaced by `rust_abi`
-
-The new `rust_abi` keyword argument is accepted by [[shared_library]],
-[[static_library]], [[library]] and [[shared_module]] functions. It can be either
-`'rust'` (the default) or `'c'` strings.
-
-`rust_crate_type` is now deprecated because Meson already knows if it's a shared
-or static library, user only need to specify the ABI (Rust or C).
-
-`proc_macro` crates are now handled by the [`rust.proc_macro()`](Rust-module.md#proc_macro)
-method.

docs/markdown/snippets/sanitizers_test.md

@@ -1,5 +0,0 @@
-## Tests now abort on errors by default under sanitizers
-
-Sanitizers like AddressSanitizer and UndefinedBehaviorSanitizer do not abort
-by default on detected violations. Meson now exports `ASAN_OPTIONS` and `UBSAN_OPTIONS`
-when unset in the environment to provide sensible abort-by-default behavior.

docs/markdown/snippets/shared_static_only_args.md

@@ -1,9 +0,0 @@
-## `<lang>_(shared|static)_args` for both_library, library, and build_target
-
-We now allow passing arguments like `c_static_args` and `c_shared_args`. This
-allows a [[both_libraries]] to have arguments specific to either the shared or
-static library, as well as common arguments to both.
-
-There is a drawback to this, since Meson now cannot re-use object files between
-the static and shared targets. This could lead to much higher compilation time
-when using a [[both_libraries]] if there are many sources.

docs/markdown/snippets/shorthand_argument_for_mtest_num_processes.md

@@ -1,4 +0,0 @@
-## `-j` shorthand for `--num-processes`
-
-`-j` now means the same thing as `--num-processes`. It was inconsistently
-supported only in some subcommands. Now you may use it everywhere

docs/markdown/snippets/string_format.md

@@ -1,10 +0,0 @@
-## Unified message(), str.format() and f-string formatting
-
-They now all support the same set of values: strings, integers, bools, options,
-dictionaries and lists thereof.
-
-- Feature options (i.e. enabled, disabled, auto) were not previously supported
-  by any of those functions.
-- Lists and dictionaries were not previously supported by f-string.
-- str.format() allowed any type and often resulted in printing the internal
-  representation which is now deprecated.

docs/markdown/snippets/subprojects_excluded_from_scanbuild.md

@@ -1,4 +0,0 @@
-## Subprojects excluded from scan-build reports
-
-The `scan-build` target, created when using the `ninja` backend with `scan-build`
-present, now excludes bugs found in subprojects from its final report.

docs/markdown/snippets/vs_module_defs_customtargetindex.md

@@ -1,8 +0,0 @@
-## vs_module_defs keyword now supports indexes of custom_target
-
-This means you can do something like:
-```meson
-defs = custom_target('generate_module_defs', ...)
-shared_library('lib1', vs_module_defs : defs[0])
-shared_library('lib2', vs_module_defs : defs[2])
-```

docs/markdown/snippets/wrap.md

@@ -1,13 +0,0 @@
-## Automatic fallback to `cmake` and `cargo` subproject
-
-CMake subprojects have been supported for a while using the `cmake.subproject()`
-module method. However until now it was not possible to use a CMake subproject
-as fallback in a `dependency()` call.
-
-A wrap file can now specify the method used to build it by setting the `method`
-key in the wrap file's first section. The method defaults to `meson`.
-
-Supported methods:
-- `meson` requires `meson.build` file.
-- `cmake` requires `CMakeLists.txt` file. [See details](Wrap-dependency-system-manual.md#cmake-wraps).
-- `cargo` requires `Cargo.toml` file. [See details](Wrap-dependency-system-manual.md#cargo-wraps).

docs/sitemap.txt

@@ -88,6 +88,7 @@ index.md
 		Wrap-best-practices-and-tips.md
 		Shipping-prebuilt-binaries-as-wraps.md
 	Release-notes.md
+		Release-notes-for-1.3.0.md
 		Release-notes-for-1.2.0.md
 		Release-notes-for-1.1.0.md
 		Release-notes-for-1.0.0.md