| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
The test does not actually fail, but the test runner seems to think
that if _anything_ gets printed to stderr, that is a failure.
https://nibblestew.blogspot.com/2019/04/an-important-message-for-people.html
|
|
Fixes: #14789
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Skip the hdf5 Fortran config-tool test when running on CI and h5fc looks
broken. This is needed due to upstream bug that h5fc does not include
include paths when built via CMake, that currently affects at least Arch
Linux and Gentoo.
Bug: https://github.com/HDFGroup/hdf5/issues/5660
Signed-off-by: Michał Górny <mgorny@quansight.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>
|
|
Check that build options fall back to host options, and that they
can be retrieved with get_option.
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>
|
|
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
|
|
Go through the whole initialization and set_option process, and check that the
option value is unaffected by the creation of a subproject.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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>
|
|
See https://github.com/mesonbuild/meson/issues/14756#issuecomment-3020599903.
When I changed Gentoo's binhost.git in a117703e74dfabc6972911504453c2492c11dead,
I'd forgot that we match those settings in Meson's CI builder, so we've
not been able to take advantage of the binpkg since then.
|
|
|
|
Previously, meson would only check if glib was part of
target.external_dependencies and add --target-glib appropriately. This
however had the downside of meson not adding --target-glib if glib was
included as a subproject, potentially breaking otherwise builds.
Instead of checking external_dependencies, check target.added_deps for
an occurrence of 'glib-2.0' and then pick the appropriate codepath
(either from the external dependency based on version_reqs or for the
internal dependency based on the actual version, potentially downgraded
to the latest release version)
Related-to: #14694
|
|
|
|
As is the case with most other methods, it must be overriden in
another compiler for it to have any use. Only the Swift compiler
uses this method at this time.
|
|
Skip if Swift 5.9 or above is not detected.
|
|
As of Swift 5.9, C++/Objective-C++ code can be mixed with Swift, and
C++ APIs can be imported to Swift. However, this must be explicitly
enabled, as it is disabled by default.
Xcode 15 introduces a new setting for this, so only set it on Xcode 15
and above.
|
|
I ran into GStreamer's CI being overwhelmed by a 5k long command line to
g-ir-scanner. This will help bypass the limitation.
See https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/532
See #6710
|
|
Those were hidden, because the global options look at
subproject `None` rather than `''`.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
To the user, toplevel project options are the same as global options
because they are not prefixed by ":". So, even if we starting printing
toplevel project overrides, we want to keep project options outside of
that section. Then one would end up with:
...
Project options
---------------
Main project:
Subproject foo:
The "Main project" line is printed because '' is in self.all_subprojects,
but there is nothing below because project options have been printed before.
To fix this, print section names lazily, together with their first content
item.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
