Update things for new release.0.51.0

25 files changed, 0 insertions, 282 deletions

diff --git a/docs/markdown/snippets/add_c17_and_c18_standards.md b/docs/markdown/snippets/add_c17_and_c18_standards.md
deleted file mode 100644
index 6461e65..0000000
--- a/docs/markdown/snippets/add_c17_and_c18_standards.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-short-description: Add c17 and c18 values for c_std option
-...
-
-## Added c17 and c18 as c_std values for recent GCC and Clang Versions
-
-For gcc version 8.0 and later, the values c17, c18, gnu17, and gnu18 were added to the accepted values for built-in compiler option c_std.
-
-For Clang version 10.0 and later on Apple OSX (Darwin), and for version 7.0 and later on other platforms, the values c17 and gnu17 were added as c_std values.
diff --git a/docs/markdown/snippets/add_fallback_argument_to_subproject_get_variable.md b/docs/markdown/snippets/add_fallback_argument_to_subproject_get_variable.md
deleted file mode 100644
index 24dafa0..0000000
--- a/docs/markdown/snippets/add_fallback_argument_to_subproject_get_variable.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-short-description: Add fallback argument to subproject.get_variable()
-...
-
-## subproject.get_variable() now accepts a `fallback` argument
-
-Similar to `get_variable`, a fallback argument can now be passed to
-`subproject.get_variable()`, it will be returned if the requested
-variable name did not exist.
-
-``` meson
-var = subproject.get_variable('does-not-exist', 'fallback-value')
-```
diff --git a/docs/markdown/snippets/cmake-prefix-path.md b/docs/markdown/snippets/cmake-prefix-path.md
deleted file mode 100644
index 15497b8..0000000
--- a/docs/markdown/snippets/cmake-prefix-path.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## 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
-search for dependencies. Now cmake can do the same, as long as the dependency
-uses a ${Name}Config.cmake file (not a Find{$Name}.cmake file), by passing
-`-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:
-```
-/tmp/dep/lib/cmake
-/tmp/dep/bin
-```
-
-then invoke meson as `meson builddir/ -Dcmake_prefix_path=/tmp/dep`
diff --git a/docs/markdown/snippets/cmake_subprojects.md b/docs/markdown/snippets/cmake_subprojects.md
deleted file mode 100644
index 07ff868..0000000
--- a/docs/markdown/snippets/cmake_subprojects.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## CMake subprojects
-
-Meson can now directly consume CMake based subprojects with the
-CMake module.
-
-Using CMake subprojects is similar to using the "normal" meson
-subprojects. They also have to be located in the `subprojects`
-directory.
-
-Example:
-
-```cmake
-add_library(cm_lib SHARED ${SOURCES})
-```
-
-```meson
-cmake = import('cmake')
-
-# Configure the CMake project
-sub_proj = cmake.subproject('libsimple_cmake')
-
-# Fetch the dependency object
-cm_lib = sub_proj.dependency('cm_lib')
-
-executable(exe1, ['sources'], dependencies: [cm_lib])
-```
-
-It should be noted that not all projects are guaranteed to work. The
-safest approach would still be to create a `meson.build` for the
-subprojects in question.
diff --git a/docs/markdown/snippets/debug-if-release-plain.md b/docs/markdown/snippets/debug-if-release-plain.md
deleted file mode 100644
index 013e6c8..0000000
--- a/docs/markdown/snippets/debug-if-release-plain.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## n_debug=if-release and buildtype=plain means no asserts
-
-Previously if this combination was used then assertions were enabled,
-which is fairly surprising behavior.
diff --git a/docs/markdown/snippets/dependency_get_variable_method.md b/docs/markdown/snippets/dependency_get_variable_method.md
deleted file mode 100644
index aaeac9c..0000000
--- a/docs/markdown/snippets/dependency_get_variable_method.md
+++ /dev/null
@@ -1,17 +0,0 @@
-## Dependency objects now have a get_variable method
-
-This is a generic replacement for type specific variable getters such as
-`ConfigToolDependency.get_configtool_variable` and
-`PkgConfigDependency.get_pkgconfig_variable`, and is the only way to query
-such variables from cmake dependencies.
-
-This method allows you to get variables without knowing the kind of
-dependency you have.
-
-```meson
-dep = dependency('could_be_cmake_or_pkgconfig')
-# cmake returns 'YES', pkg-config returns 'ON'
-if ['YES', 'ON'].contains(dep.get_variable(pkg-config : 'var-name', cmake : 'COP_VAR_NAME', default_value : 'NO'))
-  error('Cannot build your project when dep is built with var-name support')
-endif
-```
diff --git a/docs/markdown/snippets/find_library_static.md b/docs/markdown/snippets/find_library_static.md
deleted file mode 100644
index a1b7fa9..0000000
--- a/docs/markdown/snippets/find_library_static.md
+++ /dev/null
@@ -1,6 +0,0 @@
-## Add keyword `static` to `find_library`
-
-`find_library` has learned the `static` keyword. They keyword must be a boolean,
-where `true` only searches for static libraries and `false` only searches for
-dynamic/shared. Leaving the keyword unset will keep the old behavior of first
-searching for dynamic and then falling back to static.
diff --git a/docs/markdown/snippets/fortran-include.md b/docs/markdown/snippets/fortran-include.md
deleted file mode 100644
index a811765..0000000
--- a/docs/markdown/snippets/fortran-include.md
+++ /dev/null
@@ -1,12 +0,0 @@
-## 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, 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 `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 avoid deeply nested scanning of large external legacy C libraries that only interface to Fortran by `include biglib.h` or similar.
diff --git a/docs/markdown/snippets/gendeps.md b/docs/markdown/snippets/gendeps.md
deleted file mode 100644
index e724994..0000000
--- a/docs/markdown/snippets/gendeps.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## Generators have a new `depends` keyword argument
-
-Generators can now specify extra dependencies with the `depends`
-keyword argument. It matches the behaviour of the same argument in
-other functions and specifies that the given targets must be built
-before the generator can be run. This is used in cases such as this
-one where you need to tell a generator to indirectly invoke a
-different program.
-
-```meson
-exe = executable(...)
-cg = generator(program_runner,
-    output: ['@BASENAME@.c'],
-    arguments: ['--use-tool=' + exe.full_path(), '@INPUT@', '@OUTPUT@'],
-    depends: exe)
-```
diff --git a/docs/markdown/snippets/gpgme-config.md b/docs/markdown/snippets/gpgme-config.md
deleted file mode 100644
index 65569fb..0000000
--- a/docs/markdown/snippets/gpgme-config.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## gpgme dependency now supports gpgme-config
-
-Previously, we could only detect GPGME with custom invocations of `gpgme-config` or when the GPGME version was recent enough (>=1.13.0) to install pkg-config files. Now we added support to Meson allowing us to use `dependency('gpgme')` and fall back on `gpgme-config` parsing.
diff --git a/docs/markdown/snippets/intel-cl.md b/docs/markdown/snippets/intel-cl.md
deleted file mode 100644
index d866e70..0000000
--- a/docs/markdown/snippets/intel-cl.md
+++ /dev/null
@@ -1,13 +0,0 @@
-## Support for the Intel Compiler on Windows (ICL)
-
-Support has been added for ICL.EXE and ifort on windows. The support should be
-on part with ICC support on Linux/MacOS. The ICL C/C++ compiler behaves like
-Microsoft's CL.EXE rather than GCC/Clang like ICC does, and has a different id,
-`intel-cl` to differentiate it.
-
-```meson
-cc = meson.get_compiler('c')
-if cc.get_id == 'intel-cl'
-  add_project_argument('/Qfoobar:yes', language : 'c')
-endif
-```
diff --git a/docs/markdown/snippets/introRemovedTargetFiles.md b/docs/markdown/snippets/introRemovedTargetFiles.md
deleted file mode 100644
index bd86f45..0000000
--- a/docs/markdown/snippets/introRemovedTargetFiles.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## Removed the deprecated `--target-files` API
-
-The `--target-files` introspection API is now no longer available. The same
-information can be queried with the `--targets` API introduced in 0.50.0.
diff --git a/docs/markdown/snippets/kconfig.md b/docs/markdown/snippets/kconfig.md
deleted file mode 100644
index d4d5c9b..0000000
--- a/docs/markdown/snippets/kconfig.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## New module to parse kconfig output files
-
-The new module `unstable-kconfig` adds the ability to parse and use kconfig output
-files from `meson.build`.
-
diff --git a/docs/markdown/snippets/link_language.md b/docs/markdown/snippets/link_language.md
deleted file mode 100644
index 28ebe8b..0000000
--- a/docs/markdown/snippets/link_language.md
+++ /dev/null
@@ -1,10 +0,0 @@
-## New target keyword argument: `link_language`
-There may be situations for which the user wishes to manually specify the linking language.
-For example, a C++ target may link C, Fortran, etc. and perhaps the automatic detection in Meson does not pick the desired compiler.
-The user can manually choose the linker by language per-target like this example of a target where one wishes to link with the Fortran compiler:
-```meson
-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 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 override.
diff --git a/docs/markdown/snippets/linkcustom.md b/docs/markdown/snippets/linkcustom.md
deleted file mode 100644
index 0cf45ad..0000000
--- a/docs/markdown/snippets/linkcustom.md
+++ /dev/null
@@ -1,17 +0,0 @@
-## Can link against custom targets
-
-The output of `custom_target` and `custom_target[i]` can be used in `link_with` and
-`link_whole` keyword arguments. This is useful for integrating custom
-code generator steps, but note that there are many limitations:
-
- - Meson can not know about link dependencies of the custom target. If
-   the target requires further link libraries, you need to add them manually
-
- - The user is responsible for ensuring that the code produced by
-   different toolchains are compatible.
-
- - `custom_target` may only be used when it has a single output file. 
-   Use `custom_target[i]` when dealing with multiple output files.
-
- - The output file must have the correct file name extension.
-
diff --git a/docs/markdown/snippets/multiple-cross-files.md b/docs/markdown/snippets/multiple-cross-files.md
deleted file mode 100644
index de229be..0000000
--- a/docs/markdown/snippets/multiple-cross-files.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Multipe cross files can be specified
-
-`--cross-file` can be passed multiple times, with the configuration files overlaying the same way as `--native-file`.
diff --git a/docs/markdown/snippets/per-machine-options.md b/docs/markdown/snippets/per-machine-options.md
deleted file mode 100644
index d19c68e..0000000
--- a/docs/markdown/snippets/per-machine-options.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## 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
-affected native targets, that is to say all targets in native builds, and
-`native: true` targets in cross builds. Now, prefix the option with `build.` to
-affect build machine targets, and leave it unprefixed to affect host machine
-targets.
-
-For those trying to ensure native and cross builds to the same platform produced
-the same result, the old way was frustrating because very different invocations
-were needed to affect the same targets, if it was possible at all. Now, the same
-command line arguments affect the same targets everwhere --- Meson is closer to
-ignoring whether the "overall" build is native or cross, and just caring about
-whether individual targets are for the build or host machines.
diff --git a/docs/markdown/snippets/preproc-flags.md b/docs/markdown/snippets/preproc-flags.md
deleted file mode 100644
index a5e9e83..0000000
--- a/docs/markdown/snippets/preproc-flags.md
+++ /dev/null
@@ -1,12 +0,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
-`<lang>_args` options whether specified no the command-line interface (`-D..`),
-`meson.build` (`default_options`), or cross file (`[properties]`).) This was
-mostly unobservable, except for certain preprocessor-only checks like
-`check_header` would only use the preprocessor flags, leading to confusion if
-some `-isystem` was in `CFLAGS` but not `CPPFLAGS`. Now, they are lumped
-together, and `CPPFLAGS`, for the languages which are deemed to care to about,
-is just another source of compilation flags along with the others already
-listed.
diff --git a/docs/markdown/snippets/python_find_installation_modules.md b/docs/markdown/snippets/python_find_installation_modules.md
deleted file mode 100644
index a3719f2..0000000
--- a/docs/markdown/snippets/python_find_installation_modules.md
+++ /dev/null
@@ -1,9 +0,0 @@
-## New modules kwarg for python.find_installation
-
-This mirrors the modules argument that some kinds of dependencies (such as
-qt, llvm, and cmake based dependencies) take, allowing you to check that a
-particular module is available when getting a python version.
-
-```meson
-py = import('python').find_installation('python3', modules : ['numpy'])
-```
\ No newline at end of file
diff --git a/docs/markdown/snippets/sanity-check.md b/docs/markdown/snippets/sanity-check.md
deleted file mode 100644
index d5ed80d..0000000
--- a/docs/markdown/snippets/sanity-check.md
+++ /dev/null
@@ -1,17 +0,0 @@
-## Sanity checking compilers with user flags
-
-Sanity checks previously only used user-specified flags for cross compilers, but
-now do in all cases.
-
-All compilers meson might decide to use for the build are "sanity checked"
-before other tests are run. This usually involves building simple executable and
-trying to run it. Previously user flags (compilation and/or linking flags) were
-used for sanity checking cross compilers, but not native compilers.  This is
-because such flags might 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
-cross or native builds so as to make building more predictable in less-tested
-cases. Since this the user flags are necessary for cross, but not harmful for
-native, it makes more sense to use them in all sanity checks than use them in no
-sanity checks, so this is what we now do.
diff --git a/docs/markdown/snippets/sourceset.md b/docs/markdown/snippets/sourceset.md
deleted file mode 100644
index 7c09eb5..0000000
--- a/docs/markdown/snippets/sourceset.md
+++ /dev/null
@@ -1,8 +0,0 @@
-## 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
-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
-configurations.
diff --git a/docs/markdown/snippets/subproject-foreach.md b/docs/markdown/snippets/subproject-foreach.md
deleted file mode 100644
index 3a8ffc4..0000000
--- a/docs/markdown/snippets/subproject-foreach.md
+++ /dev/null
@@ -1,7 +0,0 @@
-## Add new `meson subprojects foreach` command
-
-`meson subprojects` has learned a new `foreach` command which accepts 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
-`git status` or `git diff`) before performing other actions on them.
diff --git a/docs/markdown/snippets/target-type-shared-module.md b/docs/markdown/snippets/target-type-shared-module.md
deleted file mode 100644
index e9364a1..0000000
--- a/docs/markdown/snippets/target-type-shared-module.md
+++ /dev/null
@@ -1,16 +0,0 @@
-## `target_type` in `build_targets` accepts the value 'shared_module'
-
-The `target_type` keyword argument in `build_target()` now accepts the
-value `'shared_module'`.
-
-The statement
-
-```meson
-build_target(..., target_type: 'shared_module')
-```
-
-is equivalent to this:
-
-```meson
-shared_module(...)
-```
diff --git a/docs/markdown/snippets/xfail.md b/docs/markdown/snippets/xfail.md
deleted file mode 100644
index 5392fa9..0000000
--- a/docs/markdown/snippets/xfail.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## Tests that should fail but did not are now errors
-
-You can tag a test as needing to fail like this:
-
-```meson
-test('shoulfail', exe, should_fail: true)
-```
-
-If the test passes the problem is reported in the error logs but due
-to a bug it was not reported in the test runner's exit code. Starting
-from this release the unexpected passes are properly reported in the
-test runner's exit code. This means that test runs that were passing
-in earlier versions of Meson will report failures with the current
-version. This is a good thing, though, since it reveals an error in
-your test suite that has, until now, gone unnoticed.
diff --git a/docs/markdown/snippets/xtensa-toolchain.md b/docs/markdown/snippets/xtensa-toolchain.md
deleted file mode 100644
index f75f971..0000000
--- a/docs/markdown/snippets/xtensa-toolchain.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Added basic support for the Xtensa CPU toolchain
-
-You can now use `xt-xcc`, `xt-xc++`, `xt-nm`, etc... on your cross compilation
-file and meson won't complain about an unknown toolchain.
-