| Age | Commit message (Collapse) | Author |
|---|
|
Add a clippy-json target to the ninja script.
This is useful for rust-analyzer, which requires an "external check
command" to function when not using cargo.
This also changes the --emit option in the clippy script to "emit",
without this, clippy will fail with errors about missing
libraries. These would normally be created with the normal compilation
target, but we can't rely on that, because if it fails, clippy-json
never runs, and you won't get error messages to the LSP.
|
|
|
|
|
|
Rustdoc does not yet support the --env-set parameter, change the
environment directly instead.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Filtering out this flag causes the rustdoc script to fail when
building docs for proc-macro crates.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is safer than parsing env from stdout
|
|
|
|
The entire policy system has been deprecated in Python 3.14, and is
slated for removal in 3.16. This has been caught by pylint, and is
causing CI to fail.
For our use case this is only relevant on Python 3.7 on Windows, as the
default policy on 3.8 is set to the Proactor anyway.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
cmd_line.txt is not related to serialized data, in fact it's a fallback
for when serialized data cannot be used and is also related to setting
up argparse for command line parsing. Since there is no code in common
with the rest of coredata, move it to a new module.
Fixes: #15081
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
While investigating a reproducible problem with a binary compiled with
Meson, it was notice that the RPATH entry was never removed.
By comparing the binary from 2 different build system it was observed
that altough the RPATH entry was removed (verified by the readelf -d
command) the actual path was still present causing 2 different binary.
Going deeper in the Meson build process, it was discovered that
remove_rpath_entry only deletes the entry in the '.dynamic' section but
never actually 'clean' (or better say zero-out) the path from the
.dynstr section producing binary dependendt of the build system.
To address this, introduce a new helper to to zero-out the entry from
the .dynstr section permitting to produce REAL reproducible binary.
Additional logic was needed to handle GCC linker optimization for dynstr
table where the rpath string might be reused for other dym function
string. The setion that is actually removed is filled with 'X' following
patchelf behaviour.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
|
|
|
|
|
|
(eg. tarball)
Instead of printing it out into the terminal, among other meson messages.
This is in response to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37706
which wrapped the `git` into a whole multi-line `python` call just to do exactly
what this PR does: not show an irrelevant error when building from a tarball.
|
|
|
|
As with many compilers and other tools relevant to cross-compiling,
an executable prefixed with the host architecture's GNU architecture
tuple might or might not exist, but if it does exist, we can be quite
confident that it's the appropriate executable to use for that host
architecture.
Vala's vapigen tool reads GIR XML files that can vary between
architectures (for example GLib-2.0.gir and GstAudio-1.0.gir contain
constants that take architecture-specific values), so on Debian it
needs to search an architecture-specific location. Accordingly, the
valac (>= 0.56.18-3) package provides a `${DEB_HOST_GNU_TYPE}-vapigen`
script which wraps the vapigen binary and sets appropriate search paths.
Bug-Debian: https://bugs.debian.org/1116552
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
glob can be a generator or an iterator depending on python version. We
would rather not care about this (and officially these are the same,
except not). We just pass it to "accepts_iterable". But nonetheless, we
are forced to care because we hold the value. Sad.
|
|
Reduces 3 errors that show up in newer mypy versions than pinned in CI.
It is new since 1.16 and a likely future default for mypy 2.0. It allows
things like:
```
for i in ['one', 'two', 'three']:
frob_a(i)
for i in [1, 2, 3]:
frob_b(i)
```
since "i" is obviously used as a loop holder and its type can be freely
reinvented. Note: allow-redefinition-new isn't actually about this at
all, it has greater scope than loop holders and allows redefining
"unannotated variables" of all kinds. No granularity in what to accept
redefinition of. :P
To enable this, we must also opt in to local-partial-types, which has
some overlap with None-safety. Specifically:
> the most common cases for partial types are variables initialized
> using None, but without explicit X | None annotations. By default, mypy
> won’t check partial types spanning module top level or class top level.
> This flag changes the behavior to only allow partial types at local
> level, therefore it disallows inferring variable type for None from two
> assignments in different scopes.
So with this, we also fix a couple of actual type errors this revealed.
Where possible, stop None-initializing at all -- it's not strictly
needed for global variables, anyway, and it's a coding error if it is
possible to hit these variables without defining them first.
Bug: https://github.com/python/mypy/issues/19280
|
|
|
|
--crate-type is accepted by recent versions of rustdoc, but it
is not used by it and not listed in the documentation[1].
Remove it for compatibility with old versions of Rust.
[1] https://doc.rust-lang.org/rustdoc/command-line-arguments.html
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
clang-tidy can't be ran as is on every source file and header
|
|
This splits the scanner into two discrete steps, one that scans the
source files, and one that that reads in the dependency information and
produces a dyndep.
The scanner uses the JSON format from
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html,
which is the same format the MSVC and Clang use for C++ modules
scanning. This will allow us to more easily move to using MSVC and
clang-scan-deps when possible.
As an added bonus, this correctly tracks dependencies across TU and
Target boundaries, unlike the previous implementation, which assumed
that if it couldn't find a provider that everything was good, but could
run into issues. Because of that limitation Fortran code had to fully
depend on all of it's dependencies, transitive or not. Now, when using
the dep scanner, we can remove that restriction, allowing more
parallelism.
|
|
Another rust tool, another rough copy of the code to run clippy.
Apart from the slightly different command lines, the output is in a
directory and test targets are skipped.
Knowing the output directory can be useful, so print that on successful
execution of rustdoc.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is an old method, that is now just a wrapper around the OptionStore
method, that doesn't add any value. It's also an option related method
attached to the CoreData instead of the OptionStore, so useless and a
layering violation.
|
|
Introduce an alternative to os.path.commonpath(name, path) == path,
which is a common idiom throughout Meson. Call it is_parent_path
just like the existing static method in Generator.
It is a bit faster and handles drives on Windows without the need
for an exception handler.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
|
|
It should be possible to just use the first line rather than the last.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Meson builds libraries before running clippy, thus all dependencies must be present
and clippy is run only for the warnings (instead, Cargo treats clippy as a separate
toolchain and builds everything). In Meson's case thus it is pointless to run
clippy whenever --cap-lints allow is included in the command line.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Similar to the "ninja scan-build" target for C, add a clippy internal
tool that runs clippy-driver on all crates in the project.
The approach used is more efficient than with "ninja scan-build", and
does not require rerunning Meson in a separate build directory; it
uses the introspection data to find the compiler arguments for the
target and invokes clippy-driver with a slightly modified command
line.
This could actually be applied to scan-build as well, reusing the
run_tool_on_targets() function.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This improves the handling of keyboard interrupt, and also makes it easy to
buffer the output and not mix errors from different subprocesses. This
is useful for clang-tidy and will be used by clippy as well. In addition,
the new code supports MESON_NUM_PROCESSES.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Differentiate from the "run_tool_on_targets" function that will be introduced
in the next commit.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Right now, the clang-tidy and clang-format targets use the program default
and do not let b_colorout decide whether to colorize output.
However, the wrappers that run the tool are going to be changed to buffer
output, and that would disable colorization unconditionally. So pass
a --color option to the tools and use it when building the command line.
clang-format's -fcolor-diagnostics option simply does not work, and the
"right" (or at least working) option is --color which is undocumented.
--color is present all the way back to clang 10, but I digged into
clang-format's source code to figure out what's happening. The problem
is that -fcolor-diagnostics is a complete no-operation; in fact it is
a bool that is initialized to true. gdb shows:
(gdb) p ShowColors
$2 = {<llvm::cl::Option> = {
... <llvm::cl::opt_storage<bool, false, false>> = {Value = true, ... }, ...}
on entry to clang-format's main, meaning that specifying the option on
the command line does nothing at all.
To see how clang-format determines whether to use colors you need to look
at enters SMDiagnostic::print, which simply does
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
showing once more that in fact the option cannot force-on the colors (
-fno-color-diagnostics instead works). Continuing in SMDiagnostic::print,
this RAII constructor would write the escape sequence to the terminal:
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
It ends up in WithColor::changeColor, which does
if (colorsEnabled())
OS.changeColor(Color, Bold, BG);
Digging further down, colorsEnabled() is where the Mode member is consulted:
bool WithColor::colorsEnabled() {
switch (Mode) {
case ColorMode::Enable:
return true;
case ColorMode::Disable:
return false;
case ColorMode::Auto:
return AutoDetectFunction(OS);
}
llvm_unreachable("All cases handled above.");
}
and the "AutoDetectFunction" is
static bool DefaultAutoDetectFunction(const raw_ostream &OS) {
return *UseColor == cl::BOU_UNSET ? OS.has_colors()
: *UseColor == cl::BOU_TRUE;
}
UseColor is controlled by the "--color" option, so if that option was
unset you go to OS.has_colors() even in the presence of -fcolor-diagnostics.
This has been around for over 5 years in clang-format, and it was present
even earlier, so use it in meson as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It is useful to apply a limit to the number of processes even outside "meson test",
and specifically for clang tools. In preparation for this, generalize
determine_worker_count() to accept a variable MESON_NUM_PROCESSES instead of
MESON_TESTTHREADS, and use it throughout instead of multiprocessing.cpu_count().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
`--html-nested` was added to gcovr in version 6.0 so passing
it to versions before this will result in gcovr complaining that
it doesn't recognise the argument.
Added a version check to ensure that we pass a recognised argument
for versions before 6.0
Fixes #13781
|
|
This is functionally equivalent to the logic used to locate the cross
exe_wrapper, but puts it below the "Compilers" heading rather than
"Other binaries".
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
Recent versions of the architecture-properties package provide a
cross-exe-wrapper package containing
${DEB_HOST_GNU_TYPE}-cross-exe-wrapper, which is currently a wrapper
around qemu-user but could use different emulators on each architecture
if it becomes necessary in the future.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
In Debian testing/unstable, there are wrappers available for various
GObject-Introspection tools during cross-builds, using qemu internally.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
Cross-tools on Debian generally follow the naming convention set by
Autotools AC_CHECK_TOOL, where the name is prefixed with the GNU
architecture tuple for the host architecture. env2mfile was already
using this for pkg-config, but there are many other tools that can
be detected in the same way.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
uname -s does return gnu there.
Resolves: https://github.com/mesonbuild/meson/issues/13740
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
|
|
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.
However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).
When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.
When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see #13741 for that.
Resolves: https://github.com/mesonbuild/meson/issues/13742
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
All official Debian release architectures use the Linux kernel, but
unofficial ports like hurd-i386 and kfreebsd-amd64 use the Hurd and
FreeBSD kernel, respectively.
Map Linux to 'linux' and kFreeBSD ports to 'freebsd' as per the
reference tables in Meson's documentation. For now, use the Debian
system name such as 'hurd' for anything else (see #13740 for the
question of whether Hurd should identify its kernel differently).
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
As per <https://mesonbuild.com/Reference-tables.html>, and matching what
happens when running Meson for a native build on Debian GNU/Hurd.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
This makes the frequent pattern of things like "CPU families are the
same as GNU CPUs, with a few known exceptions" less verbose.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
Separating the part that runs dpkg-architecture from the part that
interprets its results will make it easier to unit-test the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
This will make it easier to unit-test functions that work with a
MachineInfo, by constructing the expected object in a single call.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
|
|
Debian cross architectures are detected via dpkg-architecture, not via
dpkg-reconfigure.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
