llvm-config is unsuitable for standard cross-compile,
because we need to build llvm especially for it, which
is not done is almost any distros, so, for example,
standard bootstrap chroot will be unsuitable.
This patch is trying to acheive feature parity between
config-tool searching of LLVM and CMake-based one,
which is arch-agnostic.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
This test case checks stdout and demands a `dependency()` lookup fail.
The resulting error message can be different depending on whether cmake
is installed, or not. For cmake-specific tests we would simply skip the
test if cmake is not installed, but here we can just fine-tune the
pattern matching we use to determine if the test failed "correctly".
Fixes#11320
Currently Meson allow the following (Muon does not):
```meson
option('foo', type : 'boolean', value : 'true')
option('bar', type : 'integer', value : '42')
```
This is possibly a holdover from very old code, but it's a bad idea and
we should stop doing it. This deprecation is the first stop on that
journey.
We make use of allow_unknown=True here, which allows us to only look at
the common arguments in the main option parser, and then look at the
specific options in the dispatched parsers. This allows us to do more
specific checking on a per overload basis.
It is often more useful to generate shell script than dumping to stdout.
It is also important to be able to select the shell format.
Formats currently implemented:
- sh: Basic VAR=prepend_value:$VAR
- export: Same as 'sh', but also export VAR
- vscode: Same as 'sh', but without substitutions because they don't
seems to work. To be used in launch.json's envFile.
The code below this already handles being passed an Executable or
ExternalProgram, and it does it correctly, since it handles host
binaries that need an exe_wrapper correctly, while the code in the
generator paths doesn't.
The xcode backend is, like always, problematic, it doesn't handle things
the same way as the ninja and vscode backends, and generates a shell
script instead of using meson as a wrapper when needed (it seems likely
that just forcing the meson path for xcode would be better). I don't
have a working mac to develop a fix for, so I've left a todo comment
there.
Fixes: #11264
Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
Darwin-based systems, at least macOS, provide various JDK executable
stubs in
/System/Library/Frameworks/JavaVM.framework/Versions/*/Commands.
These stubs are placed in such a way that they break the heuristics of
the JNI system dependency. If a javac being analyzed to find a Java home
is a stub, use /usr/libexec/java_home.
See https://stackoverflow.com/a/15133344/7572728 for more details.
Closes#11173
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
At least, if you tried to use it when passing an install_dir. Because
T.Sequence is horrible and we should never use it, and the annotations
are a lie that produces bugs.
So, fix the annotations on CustomTarget to never allow this to happen
again, and also fix the function too. Move some definitions elsewhere
inline to satisfy the linter.
Fixes#11157
This is no longer implicitly installed due to libxslt. Actually though,
we don't need to test this in order to ensure that the custom dependency
works -- we have other jobs that test it, and the config-tool handling
itself won't suddenly fail on msys2 specifically.
When auto-generating e.g. a `clang-format` target, we first check to see
if the user has already defined one, and if so we don't bother creating
our own. We check for two things:
- if a ninja target already exists, skip
- if a run_target was defined, skip
The second check is *obviously* a duplicate of the first check. But the
first check never actually worked, because all_outputs was only
generated *after* generating all utility rules and actually writing out
the build.ninja file. The check itself compares against nothing, and
always evaluates to false no matter what.
Fix this by reordering the target creation logic so we track outputs
immediately, but only error about them later. Now, we no longer need to
special-case run_target at all, so we can drop that whole logic from
build.py and interpreter.py, and simplify the tracked state.
Fixes defining an `alias_target()` for a utility, which tried to
auto-generate another rule and errored out. Also fixes doing the same
thing with a `custom_target()` although I cannot imagine why anyone
would want to produce an output file named `clang-format` (unless clang
itself decided to migrate to Meson, which would be cool but feels
unlikely).
*.qrc files converted to C++ sources could make use of Qt headers, and
in practice for qt4 they seem to. Since this is Qt code to begin with,
it makes sense to depend on the Qt being targeted regardless of version.
In a couple of python module tests, we try to test things that rely on
the default python being the same one we look up in the python module.
This is unsolvable for the deprecated python3 module, as it actually
uses the in-process version of python for everything. For the python
module, we could actually look up the default system python instead of
the one we are running with, but then we wouldn't be testing the
functionality of that alternative python... and also the install
manifest tests would see files installed for the wrong version of
python, and report a combination of missing+extra files...
Solve both tests by just skipping the parts we cannot check.
It was only trying to guess install tag, and log missing tags, for files
installed by install_data(). Do it also for all other files, especially
custom_taget() that commonly installs generated headers.
Regression test: libccpp has both C and C++ sources. The executable only
has C sources. It should still link using the C++ compiler. When using
both_libraries the static has no sources and thus no compilers,
resulting in the executable linking using the C compiler.
https://github.com/Netflix/vmaf/issues/1107
GeneratedLists as sources to `gnome.gdbus_codegen` worked until
version 0.60 of Meson, but broke in 0.61 because of the conversion to
typed_pos_args and typed_kwargs. Reinstate this by adding them to the
decorators and annotations.
Note that gdbus_codegen desugars to two custom_targets and therefore the
generator is invoked twice. This is not optimal, but it should not be
an issue and can be changed later.
Fixes: 53a187ba2 ("modules/gnome: use typed_pos_args for gdbus_codegen", 2021-11-01)
Fixes: ef52e6093 ("modules/gnome: use typed_kwargs for gdbus_codegen", 2021-11-08)
Custom targets as sources to `gnome.gdbus_codegen` worked until version 0.60
of Meson, but broke in 0.61 because of the conversion to typed_pos_args
and typed_kwargs. Reinstate this by adding custom targets to the
decorators and annotations.
While generators also used to work, they are a bit tricky because
gdbus_codegen desugars to two custom_targets and therefore the generator
is invoked twice. This should not be a problem, but be explicit and
leave that to a separate commit to highlight the problem.
Fixes: 53a187ba2 ("modules/gnome: use typed_pos_args for gdbus_codegen", 2021-11-01)
Fixes: ef52e6093 ("modules/gnome: use typed_kwargs for gdbus_codegen", 2021-11-08)
When using both_libraries(), or library() with default_library=both, we
remove all sources from args and kwargs when building the static
library, and replace them by the objects from the shared library. But
sources could also come from any InternalDependency, in which case we
currently build them twice (not efficient) and link both objects into
the static library.
It also means that when we needlessly build those source for the static
library, it miss order dependency on generated headers that we removed
from args/kwargs, which can cause build errors in the case the source
from static lib is compiled before the header in shared lib gets
generated.
This happened in GLib:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2917.
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that “no extra build flags are used”.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Let’s introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
A subproject could have a sub-subproject as a git submodule, or part of
the subproject's release tarball, and still have a wrap file for it
(e.g. needed for [provide] section). In that case we need to use the
source tree for the sub-subproject inplace instead of downloading a new
copy into the main project.
This is the case with GLib 2.74, it has a subproject "gvdb" as git
submodule, and part of release tarball, it ships gvdb.wrap file as well.
In the debug logs, always log if a dependency lookup raises a
DependencyException. In the `required: false` case, this information
would otherwise disappear forever, and we would just not even log that
we tried it -- it doesn't appear in "(tried x, y and z)".
In the `required: true` case, we would re-raise the first exception if
it failed to be detected. Update the raise message with the same
information we print to the debug logs, indicating which dependency and
which method was used in the failing attempt.
Konstantin
Eli Schwartz
Dylan Baker
Xavier Claessens
Gijs Peskens
Thomas Li
Paolo Bonzini
Tristan Partin
Benjamin Gilbert
Marvin Scholz
David Robillard
Jussi Pakkanen
L. E. Segovia
Elliott Sales de Andrade
Jan Tojnar