Contributors ============ A total of 9 people contributed to this release. People with a "+" by their names contributed a patch for the first time. Pull requests merged ==================== A total of 17 pull requests were merged for this release. .. currentmodule:: numpy ========================= NumPy 2.5.4 Release Notes ========================= *Released on 2026-10-10.* NumPy 2.5.4 is a patch release that fixes bugs discovered after the 2.5.3 release. Highlights are: - Many typing fixes and improvements, - A workaround for the MSVC 19.51 bug, see below. This release supports Python versions 3.12-3.15. Improvements ============ - ``numpy.linalg.svd`` and ``numpy.linalg.lstsq`` now raise for inputs containing infinities instead of returning garbage results. - Fixed hangs in ``numpy.linalg.svd`` and ``numpy.linalg.lstsq`` for certain inputs containing infinities for recent versions of some LAPACK implementations. - ``numpy.linalg.cond`` now handles non-finite inputs more consistently. (`gh-32593 < >`__) StringDType hashing with NaN sentinels -------------------------------------- ``StringDType`` instances with equivalent floating-point NaN sentinels now have equal hashes. Previously, distinct NaN objects could produce equal dtype instances with different hashes, causing dictionary lookups and set deduplication to fail. (`gh-32563 < >`__) Changes ======= ``MaskedArray`` resets a fill_value that cannot be represented in a new dtype ----------------------------------------------------------------------------- A fill_value copied from a source array is now reset to the default fill_value for the new dtype when it cannot be represented in that dtype. Previously the copied value could be stale: ufuncs that change dtype left the result holding a fill_value typed for the old dtype, which raised a ``TypeError`` only when something later validated it (such as ``.view()``), and a floating point fill_value that overflows an integer dtype was kept as an out-of-range value together with a ``RuntimeWarning``. Both now fall back to the default, including when a masked array is passed to ``MaskedArray`` with a different ``dtype``. A fill_value given explicitly by the user is still validated and raises as before. This can now raise a ``ComplexWarning`` if the fill_value is complex and the new dtype is real. (`gh-32508 < >`__) (`gh-32562 < >`__) Contributors ============ A total of 9 people contributed to this release. People with a "+" by their names contributed a patch for the first time. Pull requests merged ==================== A total of 17 pull requests were merged for this release. --- title: Release 1.11.0 short-description: Release notes for 1.11.0 # New features Meson 1.11.0 was released on 13 April 2026 ## BuildTarget(install_dir) length > 1 replaced with keywords Build targets previously supported (with limited documentation) passing an array of more than one element to `install_dir:` (except in some wrappers), and would map these additional `install_dir`s to extra outputs. This was only used by Vala, and separate explicit keyword arguments are now available that provide the same functionality. Code like this: ```meson library( 'foo', 'foo.vala', install : true, install_dir : [true, get_option('includedir') / 'foo', true], ) ``` should now be written as the much clearer: ```meson library( 'foo', 'foo.vala', install : true, install_vala_header : get_option('includedir') / 'foo', install_vala_vapi : true, ) ``` Note that the default is `false` for the Vala extra outputs. ## Cargo workspace object Meson is now able to parse the toplevel `Cargo.toml` file of the project when the `workspace()` method of the Rust module is called. This guarantees that features are resolved according to what is in the `Cargo.toml` file, and in fact enables configuration of features for the build. The returned object allows retrieving features and dependencies for Cargo subprojects, and contains methods to build targets declared in `Cargo.toml` files. While Cargo subprojects remain experimental, the Meson project will try to keep the workspace object reasonably backwards-compatible. ## Cython no longer requires explicitly enabling C or C++ This only provides these languages as an implementation detail of Cython, so native C/C++ targets cannot be compiled. ## Deduplication of OpenMP linker arguments Meson now deduplicates linker arguments `-fopenmp` and `-qopenmp`. ## `meson dist` now accepts `-j`/`--num-processes` `meson dist` now supports a `-j`/`--num-processes` flag to control the number of parallel processes used during the distribution check (compilation and testing of the generated package). The `MESON_NUM_PROCESSES` environment variable is also honored, consistent with other Meson commands. ## Deprecate `should_fail` and rename it to `expected_fail`, also introduce `expected_exitcode` In 1.11.0 `should_fail` has been renamed to `expected_fail`. Before 1.11.0, there was no way to positively test a command/binary returning error/non-zero exit code when the used protocol was set to exitcode, so `expected_exitcode` has been introduced to achieve this. Do note that if the exitcode does not match the expected value, GNU skip and exit codes are still valid and the test result may be skip or error. ## The external_project module uses the cygpath command to convert paths In previous versions, the external_project module on Windows used a Windows- style path (e.g., `C:/path/to/configure`) to execute the configure file, and a relative path from the drive root (e.g., `/path/to/prefix`) as the installation prefix. However, since configure scripts are typically intended to be run in a POSIX- like environment (MSYS2, Cygwin, or GitBash), these paths were incompatible with some configure scripts. The external_project module now uses the `cygpath` command to convert the configure command path and prefix to Unix-style paths (e.g., `/c/path/to/configure` for MSYS2 and `/cygdrive/c/path/to/configure` for Cygwin). If the `cygpath` command is not found in the PATH, it will fall back to the previous behavior. ## install_man and install_headers: add support for install_tag kwarg `install_man` and `install_headers` now support the `install_tag` keyword argument, allowing selection of installed files via `meson install --tags`. Previously, `install_man` always used the `man` tag and `install_headers` always used the `devel` tag, with no way to override them. ## Added `link_early_args` to targets performing linking Options passed to the linker using the `link_args` keyword argument get placed on the command line after all objects and libraries. Some linker options, like `-u` or `--defsym`, are only useful if placed before objects and libraries as they control how the linker manipulates those. The new `link_early_args` keyword argument passes linker options which are inserted into the command line before any objects and libraries, allowing applications to use these kinds of linker options with Meson. This is currently only supported when using the `ninja` backend. ## Machine files now expand `~` as the user's home directory A new constant `~` has been added which can be used in machine files (native and cross files) to refer to the user's home directory. This is useful for specifying paths to SDKs and toolchains that are commonly installed into `~`, such as Qt, the Android SDK/NDK, or user-installed frameworks on macOS: ```ini [constants] toolchain = ~ / 'Android/sdk/ndk/27.1.12297006/toolchains/llvm/prebuilt/linux-x86_64' [binaries] c = toolchain / 'bin/clang' cpp = toolchain / 'bin/clang++' ar = toolchain / 'bin/llvm-ar' ``` Note that `~` can be used anywhere in the machine file. In the above example, the purpose of defining a new constant called `toolchain` is to not have to repeat yourself when using the path multiple times. ## `meson format` file sorting is now disabled by default and uses natural sorting The `sort_files` option to `meson format`, which sorts the arguments of `files()` invocations, is now disabled by default. If the `sort_files` option is enabled, `meson format` now sorts `files()` arguments [naturally](Style-guide.md#sorting-source-paths) rather than alphabetically. ## `-Db_lto` and `-Db_pgo` now supported for MSVC `-Db_lto` is now supported for MSVC's `/LTCG`, as is `-Db_lto_mode=thin` for `/LTCG:INCREMENTAL`. `-Db_pgo` is also supported, and should be used alongside `-Db_lto=true`. ## Last major version supporting Python 3.7, 3.8, and 3.9 Python older than 3.10 is now EOL, and Meson will drop support for these versions in the next major release, and will freely use features from 3.8, 3.9 and 3.10. Support for these versions will remain for the 1.11.x series. ## Python extension modules default to C ABI for Rust `py.extension_module()` now defaults `rust_abi` to `'c'`, so that Rust extension modules produce a `cdylib` instead of a `dylib`. This is the correct crate type for Python extension modules written in Rust, and previously had to be specified manually via `rust_crate_type: 'cdylib'` or `rust_abi: 'c'`. ## Meson now defines `QT_DEBUG` or `QT_NO_DEBUG` depending on build type When using the `qt` Meson modules, the `QT_DEBUG` or `QT_NO_DEBUG` preprocessor macro is now set depending on the value of the `debug` built-in Meson option. This mimics the behavior of `qmake`, and is expected by the `` header. ## `compiler_target()` method in the Rust module A `compiler_target()` method that returns the Rust target triple has been added to the `rust` module. This method can be useful when converting build scripts making use of Cargo's `TARGET` and `HOST` environment variables to Meson. ## Change to handling of linker arguments for Rust Since the Rust compiler integrates the compiler and linker phase, previous Meson versions did not obey `link_args`, `add_project_link_arguments` or `add_global_link_arguments`. Starting in this version, `add_project_link_arguments()`, `add_global_link_arguments()`, and the `link_args` keyword argument are supported for Rust. They wrap the arguments with `-Clink-arg=` when invoking rustc, and are only included when creating binary or shared library crates. Likewise, methods such as `has_link_argument()` now wrap the arguments being tested with `-Clink-arg=`. ## XC32 support now aware of v5.00 features XC32 features introduced in v5.00 can now be used. This includes support for LTO auto and the C2x and CPP23 standards. ## windows.compile_resources now detects header changes with rc.exe The `rc.exe` resource compiler neither provides *depfile* support nor allows showing includes, as is possible with C or C++ compilers. Therefore, changes to files included by the `.rc` file did not trigger recompilation of the resource file. A workaround was added to Meson by calling the preprocessor on the `.rc` file to display the included headers and allow ninja to record them as dependencies. ## Added `implicit_include_directories` argument to `windows.compile_resources` [Windows](Windows-module.md) module [compile_resources](Windows- module.md#compile_resources) now has an `implicit_include_directories` keyword argument to automatically add current build and source directories to the included paths when compiling a resource. --- title: Release 1.12.0 short-description: Release notes for 1.12.0 # New features Meson 1.12.0 was released on 10 August 2026 ## Custom dependency for atomic now works on MSVC `dependency('atomic')` now works on MSVC >=19.35.32124. It requires `c_std=c11` or later, otherwise the dependency will return not found. ## Support for CACHEDIR.TAG specification A CACHEDIR.TAG file (https://bford.info/cachedir/) is now created in the build directory as part of the setup and regenerate phases, allowing backup software to ignore the whole directory. ## New "clippy-json" Ninja Target For rust-analyzer A new `clippy-json` ninja target will now be generated for rust projects. rust-analyzer supports non-cargo based projects so long as you provide it with a `rust-project.json` file and a custom "check command" to provide compiler errors. Meson already for some time has generated a `rust-project.json` file for rust-analyzer, but had no way to hook up its rustc/clippy output to rust- analyzer. To use the new feature, you need to override the rust-analyzer check command as shown [in the rust-analyzer documentation](https://rust- analyzer.github.io/book/non_cargo_based_projects.html), and set it to a `ninja invocation along the lines of `ninja clippy-json -C build`. ## Add a new `default()` function and object This function and object allow setting a keyword argument to it's default value. This is especially useful for cases when a non-default value is wanted in some cases but not all. For example: ```meson library( ... name_prefix : host_machine.system() == 'windows' ? '' : default(), ) ``` ## Delay install script errors to install time Previously, `gnome.post_install` might've caused a configure to fail due to tools such as `update-desktop-database` not being installed or due to an `exe_wrapper` missing when cross-building glib. Those errors will now be delayed to install time, or not emitted at all if installing with `DESTDIR` set, since then they'll be skipped. ## find_program() now respects --force-fallback-for If a subproject listed in --force-fallback-for provides a particular program (via program_names in its wrapfile), find_program will use the program from the subproject instead of looking it up from the system. ## `fs.copyfile()` now has a `build_subdir` argument `fs.copyfile()`'s new `build_subdir` argument allows creating a file inside a subdirectory of the current build directory. ## Added `depends` kwarg to `generator.process()` The [[generator.process]] method now supports specifying `depends` as a kwarg to extend the list of dependencies for generated files. ## Added `msgfmt_args` arg to `i18n.gettext` `i18n.gettext` now supports the `msgfmt_args` argument. This argument can be used to pass additional arguments to `msgfmt` when building the translations. ```meson i18n = import('i18n') i18n.gettext('mycatalog', args : ['-k_', '-kN_'], msgfmt_args : ['--use-fuzzy']) ``` ## include_directories object now have a to_list() method The [[@inc]] object returned by [[include_directories]] now has a `to_list()` method that returns a list of strings of absolute paths. Unless the include path is a system path, there will be a path for the source root and one for the build root. ``` inc = include_directories('include') include_paths = inc.to_list() ``` ## Added integer base conversions to `str.to_int()` and `int.to_string()` Meson strings can now be converted from hexadecimal, octal, and binary integer literals with `str.to_int()`. Integers can also be formatted back to strings in those bases with `int.to_string(format:)`. ```meson assert('0xff'.to_int() == 255) assert(255.to_string(format: 'hex') == '0xff') ``` ## Multiple positional arguments for `meson wrap install` Previously `meson wrap install` only accepted a single wrap name to install. This limitation has now been lifted, and it is now possible to specify multiple wrap names for installation. The exit code will be non-zero if *any* of the wraps fail to install. ## `meson format` allows `--recursive` with `--check-diff` Previously, the `--recursive` option to `meson format` required either `--inplace` or `--output`. With this version, `--check-diff` is allowed to. ## New option `--subprojects` for `meson format` A new option `--subprojects`, to be specified together with `--recursive`, tells `meson format` to also recurse into subprojects. ## OpenHarmony (OHOS) is now recognized as an Android subsystem Meson now recognizes OpenHarmony / HarmonyOS (OHOS). OHOS behaves like Android -- applications are shared libraries, shared libraries are not versioned, and so on -- but uses musl instead of Bionic. It is therefore modelled as an Android subsystem rather than a separate system. Machine files select it in the `[host_machine]` section with: ```ini [host_machine] system = 'android' subsystem = 'ohos' ``` With this, `host_machine.system()` is `'android'` (so all Android handling applies, including unversioned `libfoo.so` output) while `host_machine.subsystem()` is `'ohos'`. When cross-compiling a CMake subproject, the toolchain file generated by the CMake module sets `CMAKE_SYSTEM_NAME = OHOS`. ## External programs as inputs and dependencies to custom targets Custom targets now allow specifying an external program in the `input` and `depends` keyword arguments. This also applies to several methods provided by modules, as they are lowered to custom targets internally. ## External programs as dependencies to tests Tests now allow specifying an external program in the `depends` keyword argument. ## Support for Python 3.7, 3.8, and 3.9 dropped Meson 1.12 is the first version to require Python version 3.10 or greater. Support for older versions of Python is maintained with bug fixes only for some LTS releases. See the [FAQ entry](FAQ.md#Do-you-at-least-support-my-ancient-python-install) for more information. ## More types of generated files allowed by `qt.preprocess` `qt.preprocess` now allows custom target indexes or generators in addition to custom targets for `ui_files`, `moc_sources` and `moc_headers`. ## The Rust module includes a basic wrapper for cbindgen This will correctly track the config.toml, and generate a rust source from the marked C files. This handles structured_sources correctly, and also handles depfile generation transparently. ## Non-default members of Cargo workspaces can now be built The new keyword argument `extra_members` to the `workspace()` method allows configuring non-default members of a Cargo workspace. Previously, non-default members were never used for dependency resolution and could not be built. ## subproject() and meson.override_find_program() now support the native keyword argument Subprojects may now be built for the host or build machine (or both). Therefore, in a cross compile setup, build-time dependencies can be built for the machine running the build. When a subproject is run for the build machine it will act just like a normal build == host setup, except that no targets will be installed. This necessarily means that `meson.override_find_program()` must differentiate between programs for the host and those for the build machine, as you may need two versions of the same program, which have different outputs based on the machine they are for. For backwards compatibility reasons the default is for the host machine. Inside a native subproject the host and build machine will both be the build machine. Cargo workspaces use this feature automatically when building procedural macro crates and their dependencies. ## `meson test` now accepts `--exclude` `meson test` has a new `--exclude` argument to allow skipping named tests. It takes a full test name and can be specified repeatedly. This should help distributions that need to skip tests irrelevant for them or known to be buggy. ## Vala cross compilation changes Traditionally Meson has used the same Vala compiler for cross and native compilation. It turned out that even though the Vala compiler generated C code, the output and its dependencies are platform dependent. Now Meson uses Vala in the same way as all other cross compilers and it can be defined in the cross file. ## `werror=true` now applies to the linker as well When `werror=true` is set, Meson now passes the appropriate fatal-warnings flag to the linker (for example `--fatal-warnings` for GNU ld, `-fatal_warnings` for Apple ld, `/WX` for MSVC link). Previously, `werror=true` only affected compiler warnings. ## Added `win_subsystem` to `shared_library()` and `shared_module()` Synonym for the one found in `executable()`. Mostly useful for setting the subsystem version in PE headers. This can affects Windows's ShimEngine, but not SxS lookups. Usually you still want to provide a manifest when targeting modern Windows. Sometime also useful for targeting other subsystems. Visual Studio backends now also properly supports setting subsystem versions. ## i18n.xgettext recursive option now includes "private" dependencies Suppose we have: ``` libA.dll -> libB.dll -> libC.dll ``` Here, `libA` links with `libB`, and `libB` links with `libC`, but `libA` does not link with `libC` directly. So, `libC` is a "private" dependency of `libB`. If we collect strings to translate using: ``` i18n.xgettext(libC) i18n.xgettext(libB) pot_file = i18n.xgettext(libA, recursive: true) ``` Previously, strings from `libC` would not be included in `pot_file`, since `libC` is not a direct link dependency of `libA`. This has been fixed: when the `recursive: true` option is used, `xgettext` now recursively includes translations from all dependencies, including those of dependencies. This is more logical, as even if `libA` does not directly link with `libC`, it may still need translated strings from `libC`.