|
|
|
---
|
|
|
|
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]] 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 you 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:
|
|
|
|
|
|
|
|
```meson
|
|
|
|
# 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 overridden by using the `darwin_versions:` kwarg to
|
|
|
|
[[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
|
|
|
|
```
|
|
|
|
|
|
|
|
## `subproject()` function now supports the `required:` kwarg
|
|
|
|
|
|
|
|
This allows you to declare an optional subproject. You can now call
|
|
|
|
`found()` on the return value of the `subproject()` call to see if the
|
|
|
|
subproject is available before calling `get_variable()` to fetch
|
|
|
|
information from it.
|
|
|
|
|
|
|
|
## `dependency()` objects now support the `.name()` method
|
|
|
|
|
|
|
|
You can now fetch the name of the dependency that was searched like
|
|
|
|
so:
|
|
|
|
|
|
|
|
```meson
|
|
|
|
glib_dep = dependency('glib-2.0')
|
|
|
|
...
|
|
|
|
message("dependency name is " + glib_dep.name())
|
|
|
|
# This outputs `dependency name is glib-2.0`
|
|
|
|
|
|
|
|
qt_dep = dependency('qt5')
|
|
|
|
...
|
|
|
|
message("dependency name is " + qt_dep.name())
|
|
|
|
# This outputs `dependency name is qt5`
|
|
|
|
|
|
|
|
decl_dep = declare_dependency()
|
|
|
|
...
|
|
|
|
message("dependency name is " + decl_dep.name())
|
|
|
|
# This outputs `dependency name is internal`
|
|
|
|
```
|