| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
The clang-tidy-fix target uses run-clang-tidy to do the fixing, however
this script itself spawns `os.cpu_count()` threads as part of its
internal parallelism. When combined with Meson's parallelism this
results in the creation of potentially thousands of unecessary threads.
This commit rewrites the clang-tidy-fix to perform the same task
run-clang-tidy does but exclusively on Meson's thread pool. "Fix-it"
snippets are saved to `meson-private/clang-tidy-fix/` by a parallel
clang-tidy phase, afterwards (to avoid races) all collected fixes are
applied with a single call to clang-apply-replacements.
|
|
It was possible (with some frequency) for the clang-tidy/format target
to continue starting new subprocesses after a CTRL-C, because we were
not canceling the already queued tasks and waiting for all of them.
This makes a best-effort attempt to cancel all further subprocesses. It
is not 100%, because there is a race that is hard to avoid (without
major restructuring, at least): new subprocesses may be started after
KeyboardInterrupt (or any other exception) is raised but before we get
to the cancellation.
When the race happens, the calling ninja may exit before Meson exits,
causing some output (from clang-tidy/format and Meson's traceback) to be
printed after returning to the shell prompt. But this is an improvement
over potentially launching all the remaining tasks after having returned
to the shell, which is what used to happen rather often.
In practice, it appears that we cleanly exit with a pretty high
probability unless CTRL-C is hit very early after starting (presumably
before the thread pool has launched subprocesses on all its threads).
|
|
|
|
Duplicated -delete_rpath arguments will cause macOS's install_name_tool
failed.
|
|
|
|
The documentation for subprocess.run at https://docs.python.org/3/library/subprocess.html#popen-constructor has a warning,
pointing to using shutil.which() instead of subprocess.run for detecting if exe files exists on the path.
shutil.which() is used in many places already.
|
|
Fixes regression in commit 78e9009ff9d36925e04f329f9082841002ddd848.
new_rpath is only set when install_rpath appears in meson.build.
Before this commit, we treated new_rpath as a single string to pass to
-add_rpath. This worked as long as new_rpath had a single rpath in it,
though for ELF we explicitly supported multiple rpaths separated with
":" (as binutils ld is quite happy with that too).
install_name_tool does not support paths with colons in it:
```
21:12 <awilfox> Load command 19 cmd LC_RPATH cmdsize 40 path /bar:/baz:/eli:/ldap (offset 12)
21:12 <awilfox> Load command 20 cmd LC_RPATH cmdsize 24 path /foo (offset 12)
21:14 <awilfox> so the result is: do not use colons
```
After commit 78e9009ff9d36925e04f329f9082841002ddd848, we simply ended
up with one load command for LC_RPATH per char in new_rpath, which was
wrong in every possible case.
What we actually need to do is pass every distinct rpath as a separate
`-add_rpath` argument, so we split it on the colons instead. We do the
same splitting to ensure proper diff'ability for ELF anyways...
Fixes #13355
|
|
This does a couple of things:
1. Scrape the `Py_GIL_DISABLED` sysconfig var, which is the best way as of today
to determine whether the target interpreter was built with `--disable-gil`
2. link against the correct libpython
3. On Windows, work around a known issue in the python.org installer with a
missing define in `pyconfig.h`, which the CPython devs have said is unlikely
to be fixed since headers are shared between the regular and free-threaded
builds in a single NSIS installer.
|
|
This adds the `-quiet` option when invoking clang-tidy for the generated
`clang-tidy` target. (Note that the `clang-tidy-fix` target already does
so.)
This prevents messages like
```
Suppressed 1084 warnings (1084 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
```
from being repeated for every file, which drowns out the actual
warnings/errors from clang-tidy when more than a few files are
processed.
Also the tip about `-header-fileter` and `-system-headers` is not very
useful here because Meson doesn't currently provide a way to supply
these options to clang-tidy.
Even with `-quiet`, clang-tidy still prints a line like `1084 warnings
generated.` for each file.
|
|
--html-nested option is used to create a separate web page for each file and directory. Each of these web pages includes the contents of file with annotations that summarize code coverage.
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>
|
