| Age | Commit message (Collapse) | Author |
|---|
|
Fixes: #4893
|
|
Which were added in Meson 1.2, but don't have entires in the reference
manual.
|
|
Previously, the documentation said that the CPU name might be amd64,
but in fact x86_64 (AMD64) machines are detected as x86_64 in both
cpu() and cpu_family() during native builds. Reference:
https://buildd.debian.org/status/fetch.php?pkg=libglvnd&arch=amd64&ver=1.7.0-1%2Bb1&stamp=1714222481&raw=0
Instead, mention the only common case for more-specific CPU names
other than 32-bit x86, namely 32-bit ARM. On Debian's autobuilders
(which are running 32-bit user-space on a 64-bit-capable CPU),
native builds genuinely do present as `armv8l`:
https://buildd.debian.org/status/fetch.php?pkg=libglvnd&arch=armhf&ver=1.7.0-1%2Bb1&stamp=1714223924&raw=0
On other machines, they might be some older CPU functionality level.
At the time of writing, cpu() *can* return amd64 when using
`meson env2mfile` on Debian systems, but I think that's a bug in
env2mfile (#13742).
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
|
|
|
|
This commit harmonizes the handling of `d_import_dirs` and
`include_directories`. The treatment of `d_import_dirs` was also
different depending on the context: in `declare_dependency` it was
treated like the `include_directories`, but in `build_target` et al,
it had special treatment. With this commit, they are all treated
by the same function. The documentation has been updated to
reflect this.
Fixes #12742
|
|
|
|
Although it's not especially common, there are certainly cases where it's
useful to pass the path to an external program to a test program.
Fixes: https://github.com/mesonbuild/meson/issues/3552
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
|
The example incorrectly uses `then` after the if condition, which is
incorrect meson syntax as meson does not support a `then` keyword.
|
|
Ref https://github.com/mesonbuild/meson/pull/9603
|
|
It's subjective but I think that breaking the sentences in this way
makes them easier to follow.
|
|
|
|
This reverts commit 9f02d0a3e5a5ffc82256391c244b1af38e41ef78.
It turns out that this does introduce a behavioral change in existing
users of ConfigurationData, which it wasn't supposed to (it was supposed
to preserve behavior there, and add a new *warning* for
EnvironmentVariables).
This breaks projects such as pulseaudio, libvirt, and probably more.
Roll back the change and try again after 1.5.0 is released.
Fixes: #13372
|
|
When trying to get the version of a program, meson was previously
hardcoded to run the binary with `--version`. This does work with the
vast majority of programs, but there are a few outliers (e.g. ffmpeg)
which have an unusual argument for printing out the version. Support
these programs by introducing a version_argument kwarg in find_program
which allows users to override `--version` with whatever the custom
argument for printing the version may be for the program.
|
|
@PLAINNAME@ and @BASENAME@ cannot be used in custom_target()
with multiple inputs. For those, similar macros are needed
with an index.
Fixes #13164
|
|
This is a similar commit to the one that added required to all the
compiler.has* functions.
|
|
This allows `cc.find_library().name()` to work, just like
`dependency().name()`.
Fixes: #13053
|
|
Only Environment and ConfigurationData are mutable. However, only
ConfigurationData becomes immutable after first use which is
inconsistent.
This deprecates modification after first use of Environment object and
clarify documentation.
|
|
That holds for all of these meson function: run_target, generator and
custom_target and additionally to the Windows and Gnome module.
|
|
Support `meson dist` when getting project versions from VCS
|
|
Fixes #10901
|
|
Fixes #6567
|
|
Followup to 7b7d2e060b447de9c2642848847370a58711ac1c which handles ASAN and UBSAN.
It turns out that MSAN needs the same treatment. I've checked other sanitizers
like HWASAN and TSAN - it looks like they may both need it too, but Meson doesn't
currently suppose those anyway (see https://github.com/mesonbuild/meson/pull/12648).
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
|
|
This was inherited from documentation of build target, but some sentences do not make sense in the context of the preprocessor.
|
|
They accept list as documented
|
|
Fixes #688
|
|
|
|
This was implemented in dc51740e2cdee171ac6ebc7ed261e5c08730c9a9,
but was not added to the documentation or marked as a new feature.
|
|
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
|
|
This is needed now that str.format() is not allowing it any more. It is
also more consistent with other objects that have that method as well,
such as build targets.
Fixes: #12406
|
|
|
|
Signed-off-by: Filipe Laíns <lains@riseup.net>
|
|
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
|
|
Do as we do for MALLOC_PERTURB and set a sensible value for both ASAN_OPTIONS
and UBSAN_OPTIONS to abort on failure and give more helpful output at the
same time. We do not set these options if the user has exported a value
themselves to allow override.
In the last week alone, I've observed two cases where people were expecting
sanitizers to abort on failure and were surprised when it didn't:
1) https://github.com/git/git/commit/252d693797912ddb2684733160170f0408b73274
2) https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/c47df433f7bc9936fc59b323ca5e53ea4a04f40e
Correct this - which is in-line with meson's DWIM/DTRT philosophy.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Which allow passing arguments specifically to the static or shared
libraries.
For design, this is all handled in the interpreter, by the build layer
the arguments are combined into the existing fields. This limits changes
required in the mid and backend layers
|
|
Way back in Meson 0.25, support was added to `vala_args` for Files.
Strangely, this was never added to any other language, though it's been
discussed before. For type safety, it makes more sense to handle this in
the interpreter level, and pass only strings into the build IR.
This is accomplished by adding a `depend_files` field to the
`BuildTarget` class (which is not exposed to the user), and adding the
depend files into that field, while converting the arguments to relative
string paths. This ensures both the proper build dependencies happen, as
well as that the arguments are always strings.
|
|
|
|
When checking target names, meson explictly forbids having multiple
targets with the same name. This is good, but it is strict and it is
impossible to have targets with the same basename and differing suffixes
(e.g. foo and foo.bin) in the same directory. Allow this for executables
by including the suffix (if it exists) in the interal target id. So foo
would be foo@exe and foo.bin would be foo.bin@exe.
|
|
fixes: #9254
|
|
Because `CustomTargetIndex`es don't have a `subdir` property, but they do
implement the `get_subdir()` method
|
|
It should refer to `add_project_arguments`, not `add_global_arguments`.
|
|
Meson already knows if it's a shared or static library, user only need
to specify the ABI (Rust or C).
|
|
This permits users who rely on following symlinks to stay on the old
default of following them.
|
|
|
|
Allow macro_name to be speficied as a parameter to configure_file().
This allows C macro-style include guards to be added to
configure_file()'s output when a template file is not given. This change
simplifies the creation of configure files that define macros with
dynamic names and want the C-style include guards.
|
|
A standard C library may not exist for cross-compile
environments, thus the existence of <stdio.h> cannot be
guaranteed.
Use <stddef.h> instead, this header contains compiler-specific
defines thus it usually comes from the compiler.
|
|
Adds a new method to the compiler object, has_define.
This makes it possible to check if a preprocessor macro/define
is set or not.
This is especially helpful if the define in question is empty,
for example:
#define MESON_EMPTY_DEFINE
This would yield the same results as a missing define with
the existing get_define method, as it would return an empty
string for both cases. Therefore this additional method is
needed.
|
|
|
|
It was listed as `bool`, but it can be a `feature` too.
|
