The Meson Build System
http://mesonbuild.com/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
339 lines
13 KiB
339 lines
13 KiB
1 year ago
|
---
|
||
|
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).
|
||
|
|