diff options
Diffstat (limited to 'docs/markdown/Release-notes-for-0.54.0.md')
| -rw-r--r-- | docs/markdown/Release-notes-for-0.54.0.md | 282 |
1 files changed, 155 insertions, 127 deletions
diff --git a/docs/markdown/Release-notes-for-0.54.0.md b/docs/markdown/Release-notes-for-0.54.0.md index 0807d2e..103d103 100644 --- a/docs/markdown/Release-notes-for-0.54.0.md +++ b/docs/markdown/Release-notes-for-0.54.0.md @@ -7,14 +7,16 @@ short-description: Release notes for 0.54.0 ## 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. +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. + +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. @@ -30,24 +32,27 @@ pkgg.generate( ## 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 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) +(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. +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 @@ -66,8 +71,8 @@ d2 = dependency('foo', version : '>=2.0', required : false, ## 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. +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: @@ -89,28 +94,30 @@ 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. +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. +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')`. +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. +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 @@ -122,7 +129,8 @@ 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. +Additionally `meson compile` provides a `--clean` switch to clean the +project. A complete list of arguments is always documented via `meson compile --help` @@ -131,16 +139,16 @@ A complete list of arguments is always documented via `meson compile --help` `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. +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`. +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') @@ -149,42 +157,48 @@ 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. +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. +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). +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')`. +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. + +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`. +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. +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. +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. +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 @@ -198,11 +212,12 @@ 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. +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. +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 @@ -212,42 +227,47 @@ As of Meson 0.54.0, the `--native-file nativefile.ini` can contain: * 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: +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. +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. +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. +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. +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. +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`. +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 @@ -257,49 +277,53 @@ The value is overridden in this order: ## 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. +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. +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. + +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. +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 +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 +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. +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. +Arguments passed to `message()` and `warning()` will be printed +separated by space. ## Added `has_tools` method to qt module @@ -325,24 +349,27 @@ repository. **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 -`<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. +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. +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 @@ -361,6 +388,7 @@ 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). +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). |