| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
This is required by meson-python to fix RPATH entries when building a wheel.
|
|
rustdoc does not support --print, and therefore the rpath argument corresponding
to the rust installation is not passed to doctests.
Forward anything that requires --print to the RustCompiler, thus fixing
doctests with a shared library dependency.
Fixes: #14813
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Rust doctests implicitly use the base target as a crate. This is not
possible unless the target uses the Rust ABI.
If someone uses a C-ABI target with rust.doctest(), you get an unresolved
module error and it is not clear what's really going on, so add a more
specific error. Cargo does the same, though it only reports a warning.
Fixes: #14813
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
clang-tidy can't be ran as is on every source file and header
|
|
This allows users to do two things, flatten potentially nested arrays
themselves, and, to safely convert types that may be an array to not an
array.
```meson
x = [meson.get_external_property('may_be_array)].flatten()
```
```meson
x = ['a', ['b', 'c']]
assert(x.flatten() == ['a', 'b', 'c'])
```
|
|
Ensure that valobj.yielding is cleared for options in the toplevel project.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This works around an issue in which meson provides absolute paths to
rustc, but rustc pulls metadata from an external rlib and adds link args
without adding library paths.
Fixes: #14622
|
|
It is too old and barfs on patches from git-format-patch:
```
Applying diff file "orc-0.4.38\0001-meson-fix-symbols-leaking-from-static-library-on-Win.patch"
patching file meson.build
Assertation failed!
Program: C:\Strawberry\c\bin\patch.EXE
File: .\src\patch\2.5.9\patch-2.5.9-src\patch.c, Line 354
Expression: hunk
```
2.6.1 is the oldest known version that works correctly.
|
|
|
|
Without adding .pxi` as a known header suffix, the added test will
fail with:
```
No specified compiler can handle file stuff.pxi
```
Technically only .pxd are header files, and .pxi are "include files"
which are literally included in .pyx files. Adding them as headers
seems to be fine though, since they're kinda similar and the point is
to avoid treating them as source files.
|
|
Avoids errors like
`ERROR: Invalid variable name: 16bit_arithmetic_dir`.
|
|
`meson.py introspect build --targets` should show
`/path/to/project/hello.c` instead of
`/path/to/project/subdir/../hello.c` if
/path/to/project/meson.build contains subdir('subdir') and
/path/to/project/subdir/meson.build contains
executable('hello', '../hello.c').
|
|
As an initial implementation, simply adding "-C prefer-dynamic" works
for binary crates (as well as dylib and proc-macro that already used it).
In the future this could be extended to other crate types. For more
information see the comment in the changed file, as well as
https://github.com/mesonbuild/meson/issues/8828 and
https://github.com/mesonbuild/meson/issues/14215.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
RustCompiler.build_rpath_args works by appending the directory to the
arguments computed by self.linker.build_rpath_args. This does not
work if there is no argument to begin with, which happens for example
in program crates.
Use the new extra_paths argument to force inclusion of the libdir into
the rpath of the binary, even in that case.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Allow adding extra directories to the rpath. Rust needs this when Rustup
is in use.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit 9ad10ee78f632a60d35327eaa9b88c7efde35fe6. The "if"
in set_option() was removed, because get_key_and_value_object_for
now always returns the subproject key and option object; remove the
function as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This makes it possible to adjust the value of the option with a
subproject-specific augment. This was an undocumented change in 1.8
which was (voluntarily) undone in commit eae4efa72 ("options: resolve
yielding options at the time they are added", 2025-07-13), but is
useful. This reimplementation of yielding options makes it possible
to presreve the bugfix while restoring this new feature.
Reported-by: Nirbheek Chauhan <nirbheek@centricular.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is a heavyweight and expensive function to use to verify that we
have a string list. Just cast to make mypy happy, we know what we have.
|
|
|
|
Optional[str]]
As a side effect, this deduplicates -D and -U arguments passed
to meson configure, taking into account the relative ordering
of -D and -U options.
Fixes: #14754
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes: #14789
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fix `scalapack.MKLPkgConfigDependency` not to crash when `MKLROOT`
is unset:
```
File "/meson/mesonbuild/dependencies/scalapack.py", line 65, in __init__
super().__init__(name, env, kwargs, language=language)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/meson/mesonbuild/dependencies/pkgconfig.py", line 322, in __init__
self._set_cargs()
~~~~~~~~~~~~~~~^^
File "/meson/mesonbuild/dependencies/scalapack.py", line 141, in _set_cargs
cflags = self.pkgconfig.cflags(self.name, allow_system, define_variable=(('prefix', self.__mklroot.as_posix()),))
^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'as_posix'
```
The code is crashing because the `_set_cargs()` method assumes that
`self.__mklroot` will always be set, presumably because it assumes
it will only be called only when `MKLPkgConfigDependency.__init__()`
finishes with `is_found = True`. However, both `_set_cargs()`
and `_set_libs()` are called during `PkgConfigDependency.__init__()`,
and therefore they will be called if pkg-config lookup succeeds even
without `MKL_ROOT` set.
To avoid the issue, check for `self.__mklroot is None` in both
functions, and raise a `DependencyException` — effectively causing
the pkg-config lookup to fail in a natural way.
Fixes #11172
Signed-off-by: Michał Górny <mgorny@quansight.com>
|
|
This is allowed -- it is already deprecated for the cross file, but it should not
assert. Add a deprecation for the native file too, and remove the assert.
Fixes: d37d649b08b832d52fa684bc0506829fb40d5261
Fixes: #14789
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes: #14788
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This commit completes 5de09cbe8838e8febf1ca3aa83b53cf06972bff3,
ensuring that only POSIX style paths are passed to the compiler
line, and thus fixing UNIX-style tools that treat single
backward slashes as Unicode escaped characters.
Fixes #12191
Completes #12534
Completes #12564
|
|
The use of os.path.join is inserting `\` into the compile_args, which
is wrong since qmake outputs `/` even on Windows, and in fact it
causes pkgconfig files that depend on qmake dependencies to have `\`
path separators, which get resolved as escape sequences.
Use Path.as_posix() to avoid this.
|
|
CUDA 12.9.0 ships a cccl that supports the new debug macros.
|
|
That is where env_opts are stored, so make the compiler call back directly
into the environment.
Suggested-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This restores the behavior before 1.8's option store refactoring.
The bug arises because c_link_args has been stored in pending_options,
and therefore the extended value (which get_global_options correctly
computes) is overwritten by the value passed on the command line.
In fact, this bug is the reason why I added the "link_args_from_envvar"
check: the CFLAGS would be ignored anyway, so I put that logic in code
instead of relying on the option store's behavior.
The fix is to extend the value *after* the option has been added and
the pending_options resolved. This requires a tiny refactoring of
the split between CoreData.add_lang_args and compilers.get_global_options.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Commit 2d1c67f09 ("options: restore special behavior of CFLAGS vs. c_args",
2025-05-15) incorrectly checked the presence of c_link_args, and did not
apply CFLAGS if c_link_args was set. This was not the behavior of 1.7,
so remove the check.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Currently, when using frameworks on MacOS systems, Meson will send the appropriate flags to the linker but fails to pass flags to the compiler, resulting in the headers not being found for the included frameworks.
This patch adds the required "-F{framework}" flag to the compiler options, so that the compiler can find the headers of included frameworks.
See: https://github.com/mesonbuild/meson/issues/14641
|
|
Fixes: #14774
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
New languages and subprojects can appear in subsequent configurations.
Subproject options are kept for later now that they are not stored
in pending_options, but compiler options for example are not. Drop
OptionStore.clear_pending so that they are preserved as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
subproject
This is already done most of the time for default_library but not in these cases.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Restore behavior of 1.7.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Remove all the special casing and late validation now that early augments
are stored in pending_subproject_options until the subproject is found.
As a result, this makes the buildtype special case operate on subprojects
as well. It also simplifies set_from_configure_command(), which does not
have to treat various kinds of options in different ways.
Fixes: #14729
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes: 8dcc9d342 ("options: accept compiler and built-in options in --reconfigure and "meson configure"", 2025-05-21
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Reserve pending_options for those that could appear later in
the configuration process. Options are added there only if
accept_as_pending_option() is true.
This is a preparation for changing the code so that it checks
pending_options for subprojects as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Remove knowledge of the internal pending_options from msetup;
operate on the command line and check against the option store.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
As shown in the test, "-Dtests=true" should not override the
subproject() call because tests is a project options and those
do not share a namespace.
Fixes: #14728
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
In get_option_std_args for the Intel C compiler, the requested command line flag is 'winlibs' which returns a list of strings of libs.
It should be 'std' as in other adjacent classes, to return the particular value of the C standard desired.
|
|
ELD updated the output for `--version` flag https://github.com/qualcomm/eld/pull/156
this commit updates detection for new output.
Signed-off-by: Kushal Pal <kushpal@qti.qualcomm.com>
|
|
This reverts commit 60d0410c0ae22fd8f37a798736973a53128b2966.
The rationale for making this change was bogus and misunderstands the
purpose of the dependency.
> The check is currently broken as atomic_flag_clear is a macro, not a
> function. Change it to test linkage instead.
... does not make any sense since the standard requires it to be a
function. We already test linkage.
> Also test if atomics work with 64-bit types. On certain platforms like
> MIPS, external libatomic is needed.
... misses the fact that we already check for external libatomic
***first***, for precisely this reason. That was in the original design
of this dependency.
Checking for more interesting forms of atomic usage is quite pointless.
You can't write code that "requires" -latomic, as the toolchain may
arbitrarily implement *anything* internally or else as a helper library,
and we can't force it to do the latter.
Instead, we:
- check if the ISO header exists, and -latomic is a valid library. If
so, assume it's needed. Maybe it is, maybe it isn't, -latomic can
always be pruned by `-Wl,--as-needed` so we refuse to clutch pearls
over it
- if -latomic doesn't exist, smoketest that the toolchain has "some kind
of atomic support". That is, the ISO header exists and one randomly
chosen function successfully links. This is not intended to be
comprehensive, it is a fallback.
Notice that unlike most dependencies with a "builtin" method, we do NOT
prefer the builtin! This is, again, because the ***primary purpose*** of
`dependency('atomic')` is to handle the fact that you should always use
-latomic if it exists.
Okay, so why revert the change? Maybe it doesn't matter? Well... that's
a problem, since it was never actually tested. The code fails with:
```
$ gcc -latomic -o /tmp/foo /tmp/foo.c
In file included from /tmp/foo.c:1:
/tmp/foo.c: In function ‘main’:
/tmp/foo.c:5:30: error: ‘b’ undeclared (first use in this function)
5 | return atomic_fetch_add(&b, 1);
| ^
/tmp/foo.c:5:30: note: each undeclared identifier is reported only once for each function it appears in
```
As it was never tested, we shall not assume it fixes a real world
problem. But it sure does break the fallback.
|
|
The check is currently broken as atomic_flag_clear is a macro, not a
function. Change it to test linkage instead.
Also test if atomics work with 64-bit types. On certain platforms like
MIPS, external libatomic is needed.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
|
|
