| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Fixes: #14476
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
These options are never looked up except by "meson configure" and
introspection, because option values are taken from self.augments[]
instead.
Fixes: #14558
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It is impossible to detect the source of default_library=both from within the
test, so add yet another knob... :(
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
We're about to lower the priority of the default_options that were passed
to subproject() and dependency() below that of machine files and command
line options.
Whenever a static dependency is falling back to a subproject, however, do
not do that. It makes no sense to build a shared library in that case.
Another possibility however could be to just make it an error.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The test covers overriding an option from the dependency() function.
If the same option is passed on the command line, it overrides the
dependency()'s default_options as well.
Tweak the description of the unittests that uses the same sources.
The tests pass, but I am not sure they should. For example in
the second test the default_library=both setting in the machine file
should have the same effect as the -D option (machine files have lower
priority than command line, but higher priority than anything in meson.build
files).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Thanks to several fixes applied between commit d37d649b0 ("Make all
Meson level options overridable per subproject.", 2025-02-13) and now,
OptionStore never gets a string key. Tighten the type of OptionDict,
and use it whenever possible.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The cmd_line_options dictionary is described as having OptionKey keys, so
make sure that cmd_the keys do have the correct type.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
self.project_options is set already a couple lines above.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
There is common logic hiding between project() and "meson configure": the
complication that the comment mentions for the "default_options" case
actually applies to "meson configure", to machine files, to command line
options and to project options. Reuse the same function in all four cases.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Suggested-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
They must be there when running re-configuring, because the backend cannot
be changed, but they can be pending on the first invocation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Once unknown options will go through accept_as_pending_option, only system options
that really exist in Meson will be accepted. Adjust the unit tests.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Starting with Meson 1.8.0, "meson configure" prints some options as
":foo" instead of "foo". Print the option as it was passed by the
user.
While at it, make errors more consistent and/or correct (e.g.
"Unknown option" instead of "Unknown options").
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Use the type that is produced by the converter, and fix the type for
methods_map which has a wrongly-placed bracket.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The converter in DEFAULT_OPTIONS makes a mapping from OptionKey to Python values,
so use the correct type.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Based on reports from the users, PGI compilers need an explicit "-o -"
on the command line to emit preprocessed output on stdout. Override
the methods in the PGICompiler mixin to add it when output goes to
stdout but not when output goes elsewhere.
Fixes: #13216
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Windows 2019 in GH Actions goes away on the 30th.
|
|
This makes all the symbols searchable from the .devhelp file.
|
|
|
|
|
|
Pointed out by Charles Brunet
|
|
Fixes https://github.com/mesonbuild/meson/issues/4668
|
|
It's needed on Darwin for the same reason it's needed on
generic UNIX. Darwin supports both LD_LIBRARY_PATH and
DYLD_LIBRARY_PATH, but the two are not quite equivalent [1],
so we set both.
[1] https://github.com/ffi/ffi/blob/29ad900a/lib/ffi/dynamic_library.rb#L40
|
|
|
|
Only support class-based dispatch, all objects have been
converted.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Do not call update() and Enum.__hash__ a gazillion times; operators
are the same for every instance of the class. In order to access
the class, just mark the methods using a decorator and build
METHODS later using __init_subclass__.
Non-primitive objects are not converted yet to keep the patch small.
They are created a lot less than other objects, especially strings
and booleans.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
