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.
308 lines
9.7 KiB
308 lines
9.7 KiB
--- |
|
title: Release 0.48 |
|
short-description: Release notes for 0.48 |
|
... |
|
|
|
# New features |
|
|
|
## Toggles for build type, optimization and vcrt type |
|
|
|
Since the very beginning Meson has provided different project types to |
|
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 |
|
e.g. 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: |
|
|
|
``` |
|
meson configure -Doptimization=g |
|
``` |
|
|
|
Similarly we have added a toggle option to select the version of |
|
Visual Studio C runtime to use. By default it uses the debug runtime |
|
DLL debug builds and release DLL for release builds but this can be |
|
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) |
|
write to the same file Meson will print a `WARNING:` message during |
|
configuration. For example: |
|
```meson |
|
project('configure_file', 'cpp') |
|
|
|
configure_file( |
|
input: 'a.in', |
|
output: 'out', |
|
command: ['./foo.sh'] |
|
) |
|
configure_file( |
|
input: 'a.in', |
|
output: 'out', |
|
command: ['./foo.sh'] |
|
) |
|
|
|
``` |
|
|
|
This will output: |
|
|
|
``` |
|
The Meson build system |
|
Version: 0.47.0.dev1 |
|
Source dir: /path/to/srctree |
|
Build dir: /path/to/buildtree |
|
Build type: native build |
|
Project name: configure_file |
|
Project version: undefined |
|
Build machine cpu family: x86_64 |
|
Build machine cpu: x86_64 |
|
Configuring out with command |
|
WARNING: Output file out for configure_file overwritten. First time written in line 3 now in line 8 |
|
Configuring out with command |
|
Build targets in project: 0 |
|
Found ninja-1.8.2 at /usr/bin/ninja |
|
``` |
|
|
|
## New kwarg `console` for `custom_target()` |
|
|
|
This keyword argument conflicts with `capture`, and is meant for |
|
commands that are resource-intensive and take a long time to |
|
finish. With the Ninja backend, setting this will add this target to |
|
[Ninja's `console` |
|
pool](https://ninja-build.org/manual.html#_the_literal_console_literal_pool), |
|
which has special properties such as not buffering stdout and |
|
serializing all targets in this pool. |
|
|
|
The primary use-case for this is to be able to run external commands |
|
that take a long time to exeute. Without setting this, the user does |
|
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 |
|
the pkg-config dependency provider. These constraints now apply to dependencies |
|
found using any dependency provider. |
|
|
|
Some combinations of dependency, host and method do not currently support |
|
discovery of the version. In these cases, the dependency will not be found if a |
|
version constraint is applied, otherwise the `version()` method for the |
|
dependency object will return `'unknown'`. |
|
|
|
(If discovering the version in one of these combinations is important to you, |
|
and a method exists to determine the version in that case, please file an issue |
|
with as much information as possible.) |
|
|
|
## python3 module is deprecated |
|
|
|
A generic module `python` has been added in Meson `0.46.0` and has a superset of |
|
the features implemented by the previous `python3` module. |
|
|
|
In most cases, it is a simple matter of renaming: |
|
```meson |
|
py3mod = import('python3') |
|
python = py3mod.find_python() |
|
``` |
|
|
|
becomes |
|
|
|
```meson |
|
pymod = import('python') |
|
python = pymod.find_installation() |
|
``` |
|
|
|
## Dictionary addition |
|
|
|
Dictionaries can now be added, values from the second dictionary overrides values |
|
from the first |
|
|
|
```meson |
|
d1 = {'a' : 'b'} |
|
d3 = d1 + {'a' : 'c'} |
|
d3 += {'d' : 'e'} |
|
``` |
|
|
|
## Dist scripts |
|
|
|
You can now specify scripts that are run as part of the `dist` |
|
target. An example usage would go like this: |
|
|
|
```meson |
|
project('foo', 'c') |
|
|
|
# other stuff here |
|
|
|
meson.add_dist_script('dist_cleanup.py') |
|
``` |
|
|
|
## Fatal warnings |
|
|
|
A new command line option has been added: `--fatal-meson-warnings`. When enabled, any |
|
warning message printed by Meson will be fatal and raise an exception. It is |
|
intended to be used by developers and CIs to 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 |
|
checking GNU style function attributes. These are not just simpler to use, they |
|
may be optimized to return fast on compilers that don't support these |
|
attributes. Currently this is true for MSVC. |
|
|
|
```meson |
|
cc = meson.get_compiler('c') |
|
if cc.has_function_attribute('aligned') |
|
add_project_arguments('-DHAVE_ALIGNED', language : 'c') |
|
endif |
|
``` |
|
|
|
Would replace code like: |
|
|
|
```meson |
|
if cc.compiles('''into foo(void) __attribute__((aligned(32)))''') |
|
add_project_arguments('-DHAVE_ALIGNED', language : 'c') |
|
endif |
|
``` |
|
|
|
Additionally, a multi argument version has been added: |
|
|
|
```meson |
|
foreach s : cc.get_supported_function_attributes(['hidden', 'alias']) |
|
add_project_arguments('-DHAVE_@0@'.format(s.to_upper()), language : 'c') |
|
endforeach |
|
``` |
|
|
|
## `gnome.generate_gir()` now optionally accepts multiple libraries |
|
|
|
The GNOME module can now generate a single gir for multiple libraries, which |
|
is something `g-ir-scanner` supported, but had not been exposed yet. |
|
|
|
gnome.generate_gir() will now accept multiple positional arguments, if none |
|
of these arguments are an `Executable` instance. |
|
|
|
## Hotdoc module |
|
|
|
A new module has been written to ease generation of |
|
[hotdoc](https://hotdoc.github.io/) based documentation. It supports |
|
complex use cases such as hotdoc subprojects (to create documentation |
|
portals) and makes it straight forward to leverage full capabilities |
|
of hotdoc. |
|
|
|
Simple usage: |
|
|
|
``` meson |
|
hotdoc = import('hotdoc') |
|
|
|
hotdoc.generate_doc( |
|
'foobar', |
|
c_smart_index: true, |
|
project_version: '0.1', |
|
sitemap: 'sitemap.txt', |
|
index: 'index.md', |
|
c_sources: ['path/to/file.c'], |
|
languages: ['c'], |
|
install: true, |
|
) |
|
``` |
|
|
|
## `i18n.merge_file()` now fully supports variable substitutions defined in `custom_target()` |
|
|
|
Filename substitutions like @BASENAME@ and @PLAINNAME@ were previously |
|
accepted but the name of the build target wasn't altered leading to |
|
colliding target names when using the substitution twice. |
|
i18n.merge_file() now behaves as custom_target() in this regard. |
|
|
|
## Projects args can be set separately for cross and native builds (potentially breaking change) |
|
|
|
It has been a longstanding bug (or let's call it a "delayed bug fix") |
|
that if yo do this: |
|
|
|
```meson |
|
add_project_arguments('-DFOO', language : 'c') |
|
``` |
|
|
|
Then the flag is used both in native and cross compilations. This is |
|
very confusing and almost never what you want. To fix this a new |
|
keyword `native` has been added to all functions that add arguments, |
|
namely `add_global_arguments`, `add_global_link_arguments`, |
|
`add_project_arguments` and `add_project_link_arguments` that behaves |
|
like the following: |
|
|
|
``` |
|
## Added to native builds when compiling natively and to cross |
|
## compilations when doing cross compiles. |
|
add_project_arguments(...) |
|
|
|
## Added only to native compilations, not used in cross compilations. |
|
add_project_arguments(..., native : true) |
|
|
|
## Added only to cross compilations, not used in native compilations. |
|
add_project_arguments(..., native : false) |
|
``` |
|
|
|
Also remember that cross compilation is a property of each |
|
target. There can be target that are compiled with the native compiler |
|
and 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. |
|
|
|
## More flexible `override_find_program()`. |
|
|
|
It is now possible to pass an `executable` to |
|
`override_find_program()` if the overridden program is not used during |
|
configure. |
|
|
|
This is particularly useful for fallback dependencies like Protobuf |
|
that also provide a tool like protoc. |
|
|
|
## `shared_library()` now supports setting dylib compatibility and current version |
|
|
|
Now, by default `shared_library()` sets `-compatibility_version` and |
|
`-current_version` of a macOS dylib using the `soversion`. |
|
|
|
This can be overriden by using the `darwin_versions:` kwarg to |
|
[`shared_library()`](Reference-manual.md#shared_library). As usual, you can |
|
also pass this kwarg to `library()` or `build_target()` and it will be used in |
|
the appropriate circumstances. |
|
|
|
## Version comparison |
|
|
|
`dependency(version:)` and other version constraints now handle versions |
|
containing non-numeric characters better, comparing versions 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 |
|
previous comparison behaviour of extending the compared 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 |
|
of `'==0.11'`, but no longer does, being instead considered strictly greater. |
|
|
|
Instead, use a version constraint which exactly compares with the precise |
|
version required, e.g. `'==0.11.0'`. |
|
|
|
## Keyword argument for GNU symbol visibility |
|
|
|
Build targets got a new keyword, `gnu_symbol_visibility` that controls |
|
how symbols are exported from shared libraries. This is most commonly |
|
used to hide implementation symbols like this: |
|
|
|
```meson |
|
shared_library('mylib', ... |
|
gnu_symbol_visibility: 'hidden') |
|
``` |
|
|
|
In this case only symbols explicitly marked as visible in the source |
|
files get exported. |
|
|
|
## Git wraps can now clone submodules automatically |
|
|
|
To enable this, the following needs to be added to the `.wrap` file: |
|
|
|
```ini |
|
clone-recursive=true |
|
```
|
|
|