title: Release 0.54.0 short-description: Release notes for 0.54.0 ...

New features

Emscripten (emcc) now supports threads

In addition to properly setting the compile and linker arguments, a new Meson builtin has been added to control the PTHREAD_POOL_SIZE option, -D<lang>_thread_count, which may be set to any integer value greater than 0. If it set to 0 then the PTHREAD_POOL_SIZE option will not be passed.

Introduce dataonly for the pkgconfig module

This allows users to disable writing out the inbuilt variables to the pkg-config file as they might actually not be required.

One reason to have this is for architecture-independent pkg-config files in projects which also have architecture-dependent outputs.

pkgg.generate(
  name : 'libhello_nolib',
  description : 'A minimalistic pkgconfig file.',
  version : libver,
  dataonly: true
)

Consistently report file locations relative to cwd

The paths for filenames in error and warning locations are now consistently reported relative to the current working directory (when possible), or as absolute paths (when a relative path does not exist, e.g. a Windows path starting with a different drive letter to the current working directory).

(The previous behaviour was to report a path relative to the source root for all warnings and most errors, and relative to cwd for certain parser errors)

dependency() consistency

The first time a dependency is found, using dependency('foo', ...), the return value is now cached. Any subsequent call will return the same value as long as version requested match, otherwise not-found dependency is returned. This means that if a system dependency is first found, it won't fallback to a subproject in a subsequent call any more and will rather return not-found instead if the system version does not match. Similarly, if the first call returns the subproject fallback dependency, it will also return the subproject dependency in a subsequent call even if no fallback is provided.

For example, if the system has foo version 1.0:

# d2 is set to foo_dep and not the system dependency, even without fallback argument.
d1 = dependency('foo', version : '>=2.0', required : false,
                fallback : ['foo', 'foo_dep'])
d2 = dependency('foo', version : '>=1.0', required : false)
# d2 is not-found because the first call returned the system dependency, but its version is too old for 2nd call.
d1 = dependency('foo', version : '>=1.0', required : false)
d2 = dependency('foo', version : '>=2.0', required : false,
                fallback : ['foo', 'foo_dep'])

Override dependency()

It is now possible to override the result of dependency() to point to any dependency object you want. The overriding is global and applies to every subproject from there on.

For example, this subproject provides 2 libraries with version 2.0:

project(..., version : '2.0')

libfoo = library('foo', ...)
foo_dep = declare_dependency(link_with : libfoo)
meson.override_dependency('foo', foo_dep)

libbar = library('bar', ...)
bar_dep = declare_dependency(link_with : libbar)
meson.override_dependency('bar', bar_dep)

Assuming the system has foo and bar 1.0 installed, and master project does this:

foo_dep = dependency('foo', version : '>=2.0', fallback : ['foo', 'foo_dep'])
bar_dep = dependency('bar')

This used to mix system 1.0 version and subproject 2.0 dependencies, but thanks to the override bar_dep is now set to the subproject's version instead.

Another case this can be useful is to force a subproject to use a specific dependency. If the subproject does dependency('foo') but the main project wants to provide its own implementation of foo, it can for example call meson.override_dependency('foo', declare_dependency(...)) before configuring the subproject.

Simplified dependency() fallback

In the case a subproject foo calls meson.override_dependency('foo-2.0', foo_dep), the parent project can omit the dependency variable name in fallback keyword argument: dependency('foo-2.0', fallback : 'foo').

Backend agnostic compile command

A new meson compile command has been added to support backend agnostic compilation. It accepts two arguments, -j and -l, which are used if possible (-l does nothing with msbuild). A -j or -l value < 1 lets the backend decide how many threads to use. For msbuild this means -m, for ninja it means passing no arguments.

meson setup builddir --backend vs
meson compile -C builddir -j0  # this is the same as `msbuild builddir/my.sln -m`
meson setup builddir
meson compile -C builddir -j3  # this is the same as `ninja -C builddir -j3`

Additionally meson compile provides a --clean switch to clean the project.

A complete list of arguments is always documented via meson compile --help

Native (build machine) compilers not always required

add_languages() gained a native: keyword, indicating if a native or cross compiler is to be used.

For the benefit of existing simple build definitions which don't contain any native: true targets, without breaking backwards compatibility for build definitions which assume that the native compiler is available after add_languages(), if the native: keyword is absent the languages may be used for either the build or host machine, but are never required for the build machine.

This changes the behaviour of the following Meson fragment (when cross-compiling but a native compiler is not available) from reporting an error at add_language to reporting an error at executable.

add_language('c')
executable('main', 'main.c', native: true)

Summary improvements

A new list_sep keyword argument has been added to summary() function. If defined and the value is a list, elements will be separated by the provided string instead of being aligned on a new line.

The automatic subprojects section now also print the number of warnings encountered during that subproject configuration, or the error message if the configuration failed.

Add a system type dependency for zlib

This allows zlib to be detected on macOS and FreeBSD without the use of pkg-config or cmake, neither of which are part of the base install on those OSes (but zlib is).

A side effect of this change is that dependency('zlib') also works with cmake instead of requiring dependency('ZLIB').

Added ‘name’ method

Build target objects (as returned by executable(), library(), ...) now have a name() method.

New option --quiet to meson install

Now you can run meson install --quiet and Meson will not verbosely print every file as it is being installed. As before, the full log is always available inside the builddir in meson-logs/install-log.txt.

When this option is passed, install scripts will have the environment variable MESON_INSTALL_QUIET set.

Numerous speed-ups were also made for the install step, especially on Windows where it is now 300% to 1200% faster than before depending on your workload.

Property support emscripten's wasm-ld

Before 0.54.0 we treated emscripten as both compiler and linker, which isn‘t really true. It does have a linker, called wasm-ld (Meson’s name is ld.wasm). This is a special version of clang's lld. This will now be detected properly.

Skip sanity tests when cross compiling

For certain cross compilation environments it is not possible to compile a sanity check application. This can now be disabled by adding the following entry to your cross file's properties section:

skip_sanity_check = true

Support for overriding the linker with ldc and gdc

LDC (the llvm D compiler) and GDC (The Gnu D Compiler) now honor D_LD linker variable (or d_ld in the cross file) and is able to pick different linkers.

GDC supports all of the same values as GCC, LDC supports ld.bfd, ld.gold, ld.lld, ld64, link, and lld-link.

Native file properties

As of Meson 0.54.0, the --native-file nativefile.ini can contain:

  • binaries
  • paths
  • properties

which are defined and used the same way as in cross files. The properties are new for Meson 0.54.0, and are read like:

x = meson.get_external_property('foobar', 'foo')

where foobar is the property name, and the optional foo is the fallback string value.

For cross-compiled projects, get_external_property() reads the cross-file unless native: true is specified.

Changed the signal used to terminate a test process (group)

A test process (group) is now terminated via SIGTERM instead of SIGKILL allowing the signal to be handled. However, it is now the responsibility of the custom signal handler (if any) to ensure that any process spawned by the top-level test processes is correctly killed.

Dynamic Linker environment variables actually match docs

The docs have always claimed that the Dynamic Linker environment variable should be ${COMPILER_VAR}_LD, but that's only the case for about half of the variables. The other half are different. In 0.54.0 the variables match. The old variables are still supported, but are deprecated and raise a deprecation warning.

Per subproject default_library and werror options

The default_library and werror built-in options can now be defined per subproject. This is useful for example when building shared libraries in the main project, but static link a subproject, or when the main project must build with no warnings but some subprojects cannot.

Most of the time this would be used either by the parent project by setting subproject's default_options (e.g. subproject('foo', default_options: 'default_library=static')), or by the user using the command line -Dfoo:default_library=static.

The value is overridden in this order:

  • Value from parent project
  • Value from subproject's default_options if set
  • Value from subproject() default_options if set
  • Value from command line if set

Environment Variables with Cross Builds

Previously in Meson, variables like CC effected both the host and build platforms for native builds, but the just the build platform for cross builds. Now CC_FOR_BUILD is used for the build platform in cross builds.

This old behavior is inconsistent with the way Autotools works, which undermines the purpose of distro-integration that is the only reason environment variables are supported at all in Meson. The new behavior is not quite the same, but doesn‘t conflict: Meson doesn’t always respond to an environment when Autoconf would, but when it does it interprets it as Autotools would.

Added ‘pkg_config_libdir’ property

Allows to define a list of folders used by pkg-config for a cross build and avoid a system directories use.

More new sample Meson templates for (Java, Cuda, and more)

Meson now ships with predefined project templates for Java, Cuda, Objective-C++, and C#, we provided with associated values for corresponding languages, available for both library, and executable.

Ninja version requirement bumped to 1.7

Meson now uses the Implicit outputs feature of Ninja for some types of targets that have multiple outputs which may not be listed on the command-line. This feature requires Ninja 1.7+.

Note that the latest version of Ninja available in Ubuntu 16.04 (the oldest Ubuntu LTS at the time of writing) is 1.7.1. If your distro does not ship with a new-enough Ninja, you can download the latest release from Ninja's GitHub page: https://github.com/ninja-build/ninja/releases

Added -C argument to meson init command

The Meson init assumes that it is run inside the project root directory. If this isn't the case, you can now use -C to specify the actual project source directory.

More than one argument to message() and warning()

Arguments passed to message() and warning() will be printed separated by space.

Added has_tools method to qt module

It should be used to compile optional Qt code:

qt5 = import('qt5')
if qt5.has_tools(required: get_option('qt_feature'))
  moc_files = qt5.preprocess(...)
  ...
endif

The MSI installer is only available in 64 bit version

Microsoft ended support for Windows 7, so only 64 bit Windows OSs are officially supported. Thus only a 64 bit MSI installer will be provided going forward. People needing a 32 bit version can build their own with the msi/createmsi.py script in Meson's source repository.

Uninstalled pkg-config files

Note: the functionality of this module is governed by Meson's rules on mixing build systems.

The pkgconfig module now generates uninstalled pc files as well. For any generated foo.pc file, an extra foo-uninstalled.pc file is placed into <builddir>/meson-uninstalled. They can be used to build applications against libraries built by Meson without installing them, by pointing PKG_CONFIG_PATH to that directory. This is an experimental feature provided on a best-effort basis, it might not work in all use-cases.

CMake find_package COMPONENTS support

It is now possible to pass components to the CMake dependency backend via the new components kwarg in the dependency function.

Added Microchip XC16 C compiler support

Make sure compiler executables are setup correctly in your path Compiler is available from the Microchip website for free

Added Texas Instruments C2000 C/C++ compiler support

Make sure compiler executables are setup correctly in your path Compiler is available from Texas Instruments website for free

Unity file block size is configurable

Traditionally the unity files that Meson autogenerates contain all source files that belong to a single target. This is the most efficient setting for full builds but makes incremental builds slow. This release adds a new option unity_size which specifies how many source files should be put in each unity file.

The default value for block size is 4. This means that if you have a target that has eight source files, Meson will generate two unity files each of which includes four source files. The old behaviour can be replicated by setting unity_size to a large value, such as 10000.

Verbose mode for meson compile

The new option --verbose has been added to meson compile that will enable more verbose compilation logs. Note that for VS backend it means that logs will be less verbose by default (without --verbose option).