diff options
Diffstat (limited to 'meson/docs/markdown/Release-notes-for-0.51.0.md')
| -rw-r--r-- | meson/docs/markdown/Release-notes-for-0.51.0.md | 337 |
1 files changed, 337 insertions, 0 deletions
diff --git a/meson/docs/markdown/Release-notes-for-0.51.0.md b/meson/docs/markdown/Release-notes-for-0.51.0.md new file mode 100644 index 000000000..cd94f6aff --- /dev/null +++ b/meson/docs/markdown/Release-notes-for-0.51.0.md @@ -0,0 +1,337 @@ +--- +title: Release 0.51.0 +short-description: Release notes for 0.51.0 +... + +# New features + +## (C) Preprocessor flag handling + +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 checking compilers with user flags + +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. + +## New `sourceset` module + +A 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. + +## n_debug=if-release and buildtype=plain means no asserts + +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 + +```meson +build_target(..., target_type: 'shared_module') +``` + +is equivalent to this: + +```meson +shared_module(...) +``` + +## New modules kwarg for python.find_installation + +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. + +```meson +py = import('python').find_installation('python3', modules : ['numpy']) +``` + +## Support for the Intel Compiler on Windows (ICL) + +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. + +```meson +cc = meson.get_compiler('c') +if cc.get_id == 'intel-cl' + add_project_argument('/Qfoobar:yes', language : 'c') +endif +``` + +## Added basic support for the Xtensa CPU toolchain + +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. + + +## Dependency objects now have a get_variable method + +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. + +```meson +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 +``` + +## CMake prefix path overrides + +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 builddir/ -Dcmake_prefix_path=/tmp/dep` + +## Tests that should fail but did not are now errors + +You can tag a test as needing to fail like this: + +```meson +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. + +## New target keyword argument: `link_language` + +There 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: + +```meson +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. + +## New module to parse kconfig output files + +The new module `unstable-kconfig` adds the ability to parse and use +kconfig output files from `meson.build`. + + +## Add new `meson subprojects foreach` command + +`meson 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. + + +## Added c17 and c18 as c_std values for recent GCC and Clang Versions + +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. + +## gpgme dependency now supports gpgme-config + +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. + +## Can link against custom targets + +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 can not 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. + + +## Removed the deprecated `--target-files` API + +The `--target-files` introspection API is now no longer available. The same +information can be queried with the `--targets` API introduced in 0.50.0. + +## Generators have a new `depends` keyword argument + +Generators 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. + +```meson +exe = executable(...) +cg = generator(program_runner, + output: ['@BASENAME@.c'], + arguments: ['--use-tool=' + exe.full_path(), '@INPUT@', '@OUTPUT@'], + depends: exe) +``` + +## Specifying options per mer machine + +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. + + +## subproject.get_variable() now accepts a `fallback` argument + +Similar 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. + +``` meson +var = subproject.get_variable('does-not-exist', 'fallback-value') +``` + +## Add keyword `static` to `find_library` + +`find_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. + +## Fortran `include` statements recursively parsed + +While 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 superceded 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. + +## CMake subprojects + +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: + +```cmake +add_library(cm_lib SHARED ${SOURCES}) +``` + +```meson +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. + +## Multiple cross files can be specified + +`--cross-file` can be passed multiple times, with the configuration files overlaying the same way as `--native-file`. |