The reference manual states that the optional value argument to
dep.as_system() defaults to 'preserve'. In practice, omitting the
argument makes the dependency use the 'system' include type.
Update the documentation to describe the actual default behavior.
Fixes#13294
clean up
fix tests for windows paths mimicing what was done in other unit tests (e.g., test case 74)
Update mesonbuild/interpreter/interpreterobjects.py
Co-authored-by: Charles Brunet <charles.brunet@optelgroup.com>
Update docs/markdown/snippets/include_directories_to_list.md
Co-authored-by: Charles Brunet <charles.brunet@optelgroup.com>
Update mesonbuild/interpreter/interpreterobjects.py
Co-authored-by: Charles Brunet <charles.brunet@optelgroup.com>
Update docs/yaml/objects/inc.yaml
Co-authored-by: Charles Brunet <charles.brunet@optelgroup.com>
Fix comment language
The current situation in Meson is that subprojects are always built for
the host machine. This means that while cross compiling, a tool that
must be run on the build machine must have all of its dependencies met
by the system (pkg-config, cmake, config-tool, etc); but dependencies
for the host machine can be built. With this patch subprojects may also
be built for the build machine.
Nothing should ever be installed from a subproject for the build
machine, while cross compiling. However, if we are not cross compiling
they are installed, since Meson can't really tell the difference between
a host and build dependency in that case.
Extracted from a patch by Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The type check fix in _BASE_LANG_KW is all that's needed since
__convert_file_args already handles File objects correctly (converts
to path string + adds to depend_files for rebuild tracking). In fact,
the vala_args case 569 already had (str, File). This just brings
the other languages in line.
Fixes: #1633
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Previous version of Meson were returning an Executable instead of
the LocalProgram.
While at it, add CustomTargetIndex to the type as well - it is
included in the KwargInfo but not in the TypedDict.
Fixes: #15774
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Previous version of Meson were returning an Executable instead of
the LocalProgram, so allow it again; use a convertor so that
the LocalProgram is resolved to the underlying file or target.
Add support for ExternalProgram while at it.
Fixes: #15774
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The 1.10 behavior is that setting `install_dir : X` is equal to
`install_dir : [X, false, false, false]`. But in
87d721fc24, the behavior was changed so
that `install_dir : [X]` would be equal to `install_dir : [X, X, X,
X]`. This breaks a large number of projects using vala.
A test is included for the original behavior
Closes: #15665
For an end user it's opaque what these extra dirs do (even if in the
backend it's a fine data layout). Additionally, it isn't exactly obvious
that passing `install_dir : [true, true, true, true]` isn't valid if
`vala_gir` isn't set. This makes things much more obvious, and means
that an end user only needs to set values they want to overwrite.
Consider this:
```meson
library(
'foo',
'foo.vala',
vala_gir : 'foo.gir',
install : true,
install_dir : [true, true, true, get_option('datadir') / 'mygir'],
)
```
The end use needs to know what all of these fields mean, and they need
to specify *every* field. Consider now:
```meson
library(
'foo',
'foo.vala',
vala_gir : 'foo.gir',
install : true,
install_vala_gir_dir : get_option('datadir') / 'mygir',
)
```
This does not change the backend representation, since that works and is
mostly fine. There's probably some improvements that could be made to
group outputs and their install status together in such a way that we
cant have mismatched lists, but I haven't undertaken that here.
Prior to commit a6ddf2534 ("backend/ninja: Extend IncludeDirs.rel_string_list
for backend use"), when include_directories() was called with
`is_system: true` and multiple directories, the resulting `-isystem`
flags appeared on the command line in the opposite order from what was
specified: the last-listed directory was searched first by the compiler.
This was the opposite convention from non-system -I includes, where the
first-listed directory is searched first.
The asymmetry was not intentional; it was a side effect of how
CompilerArgs.__iadd__ handles flags that are not in prepend_prefixes:
- `-I` is in CLikeCompilerArgs.prepend_prefixes, so `__iadd__`
prepends it. The ninja backend iterates directories in reversed
order and adds them one at a time; the prepend-on-each-add
counteracts the reversal, producing the original order.
- `-isystem` was not in prepend_prefixes, so __iadd__ appended it.
The same reversed one-at-a-time iteration then produced a reversed
sequence — the last-listed directory ended up first on the command line.
Commit a6ddf25634 changed generate_inc_dir to add all directories
in a single bulk commands += call instead of one at a time. This
preserved the correct order for -I (the double reversal in
__iadd__ still works for a bulk add) but silently broke -isystem,
because appending a list at once preserves input order rather than
reversing it.
Undo the changes a6ddf25634 to preserve the previous behavior.
Adding -isystem to prepend_prefixes would also make the ordering
consistent, but projects that relied on the old reversed
behaviour would silently break.
The correct type for use in docs/yaml is "array[str]", not "list[str]".
Fix it so that CI works.
Use the right name even in Rust-module.md, even though it does not use
the automatic converter.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This parameter provides a way to specify linker arguments that are
inserted in the command line before any input files or libraries.
In the ninjabackend, this is done by adding these to the ARGS
parameter during linking as that is placed in the command line before
the input file and libraries are processed.
Signed-off-by: Keith Packard <keithp@keithp.com>
By default install_man uses 'man' tag for it files which not always is desirable,
for example if project uses plugin functionality and plugin wants to install its own man files
it was not possible using `meson install --tags xxx`.
With this patch is now possible set desired install_tag for install_man command.
The sample output for the example failed to jibe with reality
in several ways:
- 'prefix' was not included in the inputs, so it isn't displayed
- Boolean values are printed lowercase ('true', not 'True')
- The array formatting would be properly aligned
This can come in handy for instance when a custom target creates both
headers and sources. Slicing the output of a `to_list()` call provides
convenient access to just the headers or just the sources.
Since commit 44ce04537 ("cargo: Add library API version into its name", 2025-10-28),
the target names provided by cargo subprojects have a suffix corresponding to the
library API; for example, the target that used to be "gtk4" is now "gtk4+0_10".
This however is an implementation detail, and the change broke rust_dependency_maps
that expected to use the crate name.
While the target name is preferrable, and will work great when Meson is able
to create dependency maps by itself (as is the case for the Cargo interpreter),
preserve the old behavior by checking also the entry corresponding to the result
of _get_rust_crate_name.
Reported-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In case of python and especially in the case of pyInstaller
where the python command is meson.exe runpython, it should
not be full path to be used but cmd_array.
Fixing #13834
Place the build products in a directory of the specified name
somewhere within the build directory. This allows use of the target
that includes a specific directory name:
#include <subdir/configure.h>
This also allows creating targets with the same basename by using
different subdirectory names.
v2:
Move build_subdir to Target class.
Error if path separator in build_dir
v3:
Rename to 'build_subdir' to make it clear that the name is
appended to a meson-specific build directory, and does not
provide the user with a way to define the overall meson build
hierarchy.
Allow build_subdir to include path separators.
Support 'build_subdir' for configure_file.
build_subdir must not exist in the source directory and
must not contain '..'
Add documentation and tests
v4:
Rebase and prepare for version 1.9.1
Add failing test case when build_subdir is present in the
project.
Add release note snippet
v5:
Clarify wording on restrictions on the value of build_subdir. Use
the same wording in each place this restriction is described.
v6:
Move path validation to shared function, validate_build_subdir,
instead of duplicating the tests in two places.
v7:
Update version numbers to 1.10.0
Add TypedDict updates.
Remove spurious build_subdir instance variable
v8:
Oops, missed one version number update.
Signed-off-by: Keith Packard <keithp@keithp.com>
Defining public API in a cross platform library is painful, especially
on Windows. Since every library have to define pretty much the same
macros, better do it in Meson.
Cuda, for example, doesn't use `prefer_static`, and will always link
statically unless the static value is explicitly set to `true`. This
updates the documentation to reflect that.
This reverts https://github.com/mesonbuild/meson/pull/15107
Explicit objections regarding the design were raised and not answered,
so it shouldn't have been merged. It needs to be discussed and
revisited.
