In some cases it may be necessary to set PKG_CONFIG_SYSROOT_DIR, like
when you've mounted a host architecture system in an arbitrary path.
Meson will now check the cross files for a [properties]:sys_root
variable and set the PKG_CONFIG_SYSROOT_DIR environment variable based
on that variable.
Fixes#3801Fixes#4057
* c_function_attributes: remove 'protected' from 'visibility'
This doesn't exist on macos with the apple compiler, which always causes
failures.
Fixes#5530
* compilers: Add split visibility checks to has_function_attribute
These check for a single visibility at a time, rather than all four at
once. This allows for finer grained searches, and should make using
these checks safer across operating systems.
This mirrors the modules keyword argument that some dependencies (such
as qt and llvm) take. This allows an easier method to determine if
modules are installed.
In QEMU a single set of source files is built against many different
configurations in order to generate many executable. Each executable
includes a different but overlapping subset of the source files; some
of the files are compiled separately for each output, others are
compiled just once.
Using Makefiles, this is achieved with a complicated mechanism involving
a combination of non-recursive and recursive make; Meson can do better,
but because there are hundreds of such conditional rules, it's important
to keep meson.build files brief and easy to follow. Therefore, this
commit adds a new module to satisfy this use case while preserving
Meson's declarative nature.
Configurations are mapped to a configuration_data object, and a new
"source set" object is used to store all the rules, and then retrieve
the desired set of sources together with their dependencies.
The test case shows how extract_objects can be used to satisfy both
cases, i.e. when the object files are shared across targets and when
they have to be separate. In the real-world case, a project would use
two source set objects for the two cases and then do
"executable(..., sources: ... , objects: ...)". The next commit
adds such an example.
From (almost) all points of view, the Xtensa toolchain can be treated as
a regular GCC toolchain.
This patch adds very basic support so that, at least, meson does not
fail when trying to use "xt-xcc" (which makes it possible to use it
without problems).
Since gpgme 1.13.0, pkg-config files are available and this is the
preferred way to detect the dependency. Without this, projects that wish
to generate pkg-config files that Requires.private on gpgme, now have
their custom dependency() fallbacks overridden with an incorrect
configtool dependency.
Sometimes it is convenient to run an arbitrary command (e.g. 'git diff')
on all subprojects.
Add a 'meson subprojects foreach' command to take care of that.
For this command the common argument 'subprojects' does not make sense,
so only add '--sourcedir' and cover the case of a missing
options.subprojects in run().
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
- Add libraries from InternalDependency.libraries
- Deprecate association of libraries from the "libraries" keyword
argument to the generated pkg-config file.
This variant was added to allow introspection before configuring a build
directory. This is useful for IDE integration to allow displaying and/or
setting options for the initial configuration of the build directory.
It also allows showing basic information about the project even if it's
not yet configured or configuring failed.
The project 'name' field in --projectinfo is used inconsistently:
For the top level project it always shows the name configured in
the top level meson.build file. For subprojects it's referring to the
name of the directory the subproject's meson.build is contained in.
To have a consistent output and preserve the existing behavior this adds
the 'descriptive_name' field which always shows the name set in the
project.
To be consistent the 'descriptive_name' field was also added to the
--projectfiles variant that uses an already configured build.
It also extends the information shown with the list of buildsystem-files.
This is currently only implemented in the variant for unconfigured
projects.
Dylan Baker