--- 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_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: ```meson # 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) ``` ```meson # 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: ```meson 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: ```meson 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. ```console meson builddir --backend vs meson compile -C builddir -j0 # this is the same as `msbuild builddir/my.sln -m` ``` ```console meson 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 overiding 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: ```meson 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 repond 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](https://ninja-build.org/manual.html#ref_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](https://packages.ubuntu.com/search?keywords=ninja-build&searchon=names&suite=xenial-backports§ion=all) (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: ```meson 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](Mixing-build-systems.md). 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 `/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).