title: Release 0.51.0 short-description: Release notes for 0.51.0 ...
Meson previously stored CPPFLAGS and per-language compilation flags separately. (That latter would come from CFLAGS, CXXFLAGS, etc., along with <lang>_args options whether specified no the command-line interface (-D..), meson.build (default_options), or cross file ([properties]).) This was mostly unobservable, except for certain preprocessor-only checks like check_header would only use the preprocessor flags, leading to confusion if some -isystem was in CFLAGS but not CPPFLAGS. Now, they are lumped together, and CPPFLAGS, for the languages which are deemed to care to about, is just another source of compilation flags along with the others already listed.
Sanity checks previously only used user-specified flags for cross compilers, but now do in all cases.
All compilers Meson might decide to use for the build are “sanity checked” before other tests are run. This usually involves building simple executable and trying to run it. Previously user flags (compilation and/or linking flags) were used for sanity checking cross compilers, but not native compilers. This is because such flags might be essential for a cross binary to succeed, but usually aren't for a native compiler.
In recent releases, there has been an effort to minimize the special-casing of cross or native builds so as to make building more predictable in less-tested cases. Since this the user flags are necessary for cross, but not harmful for native, it makes more sense to use them in all sanity checks than use them in no sanity checks, so this is what we now do.
sourceset moduleA new module, sourceset, was added to help building many binaries from the same source files. Source sets associate source files and dependencies to keys in a configuration_data object or a dictionary; they then take multiple configuration_data objects or dictionaries, and compute the set of source files and dependencies for each of those configurations.
Previously if this combination was used then assertions were enabled, which is fairly surprising behavior.
target_type in build_targets accepts the value ‘shared_module’The target_type keyword argument in build_target() now accepts the value 'shared_module'.
The statement
build_target(..., target_type: 'shared_module')
is equivalent to this:
shared_module(...)
This mirrors the modules argument that some kinds of dependencies (such as qt, llvm, and cmake based dependencies) take, allowing you to check that a particular module is available when getting a python version.
py = import('python').find_installation('python3', modules : ['numpy'])
Support has been added for ICL.EXE and ifort on windows. The support should be on part with ICC support on Linux/MacOS. The ICL C/C++ compiler behaves like Microsoft's CL.EXE rather than GCC/Clang like ICC does, and has a different id, intel-cl to differentiate it.
cc = meson.get_compiler('c') if cc.get_id == 'intel-cl' add_project_argument('/Qfoobar:yes', language : 'c') endif
You can now use xt-xcc, xt-xc++, xt-nm, etc... on your cross compilation file and Meson won't complain about an unknown toolchain.
This is a generic replacement for type specific variable getters such as ConfigToolDependency.get_configtool_variable and PkgConfigDependency.get_pkgconfig_variable, and is the only way to query such variables from cmake dependencies.
This method allows you to get variables without knowing the kind of dependency you have.
dep = dependency('could_be_cmake_or_pkgconfig') # cmake returns 'YES', pkg-config returns 'ON' if ['YES', 'ON'].contains(dep.get_variable(pkgconfig : 'var-name', cmake : 'COP_VAR_NAME', default_value : 'NO')) error('Cannot build your project when dep is built with var-name support') endif
When using pkg-config as a dependency resolver we can pass -Dpkg_config_path=$somepath to extend or overwrite where pkg-config will search for dependencies. Now cmake can do the same, as long as the dependency uses a ${Name}Config.cmake file (not a Find{$Name}.cmake file), by passing -Dcmake_prefix_path=list,of,paths. It is important that point this at the prefix that the dependency is installed into, not the cmake path.
If you have installed something to /tmp/dep, which has a layout like:
/tmp/dep/lib/cmake /tmp/dep/bin
then invoke Meson as meson setup builddir/ -Dcmake_prefix_path=/tmp/dep
You can tag a test as needing to fail like this:
test('shoulfail', exe, should_fail: true)
If the test passes the problem is reported in the error logs but due to a bug it was not reported in the test runner‘s exit code. Starting from this release the unexpected passes are properly reported in the test runner’s exit code. This means that test runs that were passing in earlier versions of Meson will report failures with the current version. This is a good thing, though, since it reveals an error in your test suite that has, until now, gone unnoticed.
link_languageThere may be situations for which the user wishes to manually specify the linking language. For example, a C++ target may link C, Fortran, etc. and perhaps the automatic detection in Meson does not pick the desired compiler. The user can manually choose the linker by language per-target like this example of a target where one wishes to link with the Fortran compiler:
executable(..., link_language : 'fortran')
A specific case this option fixes is where for example the main program is Fortran that calls C and/or C++ code. The automatic language detection of Meson prioritizes C/C++, and so an compile-time error results like undefined reference to main, because the linker is C or C++ instead of Fortran, which is fixed by this per-target override.
The new module unstable-kconfig adds the ability to parse and use kconfig output files from meson.build.
meson subprojects foreach commandmeson subprojects has learned a new foreach command which accepts a command with arguments and executes it in each subproject directory.
For example this can be useful to check the status of subprojects (e.g. with git status or git diff) before performing other actions on them.
For gcc version 8.0 and later, the values c17, c18, gnu17, and gnu18 were added to the accepted values for built-in compiler option c_std.
For Clang version 10.0 and later on Apple OSX (Darwin), and for version 7.0 and later on other platforms, the values c17 and gnu17 were added as c_std values.
Previously, we could only detect GPGME with custom invocations of gpgme-config or when the GPGME version was recent enough (>=1.13.0) to install pkg-config files. Now we added support to Meson allowing us to use dependency('gpgme') and fall back on gpgme-config parsing.
The output of custom_target and custom_target[i] can be used in link_with and link_whole keyword arguments. This is useful for integrating custom code generator steps, but note that there are many limitations:
Meson cannot know about link dependencies of the custom target. If the target requires further link libraries, you need to add them manually
The user is responsible for ensuring that the code produced by different toolchains are compatible.
custom_target may only be used when it has a single output file. Use custom_target[i] when dealing with multiple output files.
The output file must have the correct file name extension.
--target-files APIThe --target-files introspection API is now no longer available. The same information can be queried with the --targets API introduced in 0.50.0.
depends keyword argumentGenerators can now specify extra dependencies with the depends keyword argument. It matches the behaviour of the same argument in other functions and specifies that the given targets must be built before the generator can be run. This is used in cases such as this one where you need to tell a generator to indirectly invoke a different program.
exe = executable(...) cg = generator(program_runner, output: ['@BASENAME@.c'], arguments: ['--use-tool=' + exe.full_path(), '@INPUT@', '@OUTPUT@'], depends: exe)
Previously, no cross builds were controllable from the command line. Machine-specific options like the pkg-config path and compiler options only affected native targets, that is to say all targets in native builds, and native: true targets in cross builds. Now, prefix the option with build. to affect build machine targets, and leave it unprefixed to affect host machine targets.
For those trying to ensure native and cross builds to the same platform produced the same result, the old way was frustrating because very different invocations were needed to affect the same targets, if it was possible at all. Now, the same command line arguments affect the same targets everywhere --- Meson is closer to ignoring whether the “overall” build is native or cross, and just caring about whether individual targets are for the build or host machines.
fallback argumentSimilar to get_variable, a fallback argument can now be passed to subproject.get_variable(), it will be returned if the requested variable name did not exist.
var = subproject.get_variable('does-not-exist', 'fallback-value')
static to find_libraryfind_library has learned the static keyword. They keyword must be a boolean, where true only searches for static libraries and false only searches for dynamic/shared. Leaving the keyword unset will keep the old behavior of first searching for dynamic and then falling back to static.
include statements recursively parsedWhile non-standard and generally not recommended, some legacy Fortran programs use include directives to inject code inline. Since v0.51, Meson can handle Fortran include directives recursively.
DO NOT list include files as sources for a target, as in general their syntax is not correct as a standalone target. In general include files are meant to be injected inline as if they were copy and pasted into the source file.
include was never standard and was superseded by Fortran 90 module.
The include file is only recognized by Meson if it has a Fortran file suffix, such as .f .F .f90 .F90 or similar. This is to avoid deeply nested scanning of large external legacy C libraries that only interface to Fortran by include biglib.h or similar.
Meson can now directly consume CMake based subprojects with the CMake module.
Using CMake subprojects is similar to using the “normal” Meson subprojects. They also have to be located in the subprojects directory.
Example:
add_library(cm_lib SHARED ${SOURCES})
cmake = import('cmake') # Configure the CMake project sub_proj = cmake.subproject('libsimple_cmake') # Fetch the dependency object cm_lib = sub_proj.dependency('cm_lib') executable('exe1', ['sources'], dependencies: [cm_lib])
It should be noted that not all projects are guaranteed to work. The safest approach would still be to create a meson.build for the subprojects in question.
--cross-file can be passed multiple times, with the configuration files overlaying the same way as --native-file.