diff options
Diffstat (limited to 'docs/markdown/Release-notes-for-0.51.0.md')
| -rw-r--r-- | docs/markdown/Release-notes-for-0.51.0.md | 128 |
1 files changed, 68 insertions, 60 deletions
diff --git a/docs/markdown/Release-notes-for-0.51.0.md b/docs/markdown/Release-notes-for-0.51.0.md index 8a73cbcb1..3b57ca019 100644 --- a/docs/markdown/Release-notes-for-0.51.0.md +++ b/docs/markdown/Release-notes-for-0.51.0.md @@ -8,38 +8,41 @@ short-description: Release notes for 0.51.0 ## (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 +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. +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. +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. +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 +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 @@ -69,9 +72,10 @@ 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. +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']) @@ -79,10 +83,10 @@ 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. +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') @@ -93,8 +97,8 @@ 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. +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 @@ -118,11 +122,13 @@ 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. +`-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: ``` @@ -162,7 +168,7 @@ 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 +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 @@ -176,11 +182,12 @@ 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. +`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. +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 @@ -243,18 +250,19 @@ cg = generator(program_runner, ## 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. +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. +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 @@ -269,26 +277,27 @@ 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. +`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, +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 +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 +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. @@ -326,4 +335,3 @@ 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`. - |