This way the `rust.bindgen` can generate a second output being a C file,
which contains wrapper functions for static inline ones.
This output file can then be compiled via C targets.
Followup to 7b7d2e060b which handles ASAN and UBSAN.
It turns out that MSAN needs the same treatment. I've checked other sanitizers
like HWASAN and TSAN - it looks like they may both need it too, but Meson doesn't
currently suppose those anyway (see https://github.com/mesonbuild/meson/pull/12648).
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
These are much easier to handle as one commit since msetup calls mconf
internally. This has found one case where things are being carefully
crafted to work in mconf even though msetup has slightly different
options
Instead of being instance state, it's passed around. This isn't a big
deal internally since most of the users are protected, and the only time
an external change is required is a couple of places in msubprojects,
which is fine because the information is available.
Fixes: #12869
These aren't meant to be called externally. Additionally, they expect
some statefulness from the `resolve()` method, and by making them
protected we can more easily remove this statefulness.
Followup to commit 5c479d7a13.
In this case, PEP 668 was created to allow a thing that Debian wanted,
which is for `pip install foobar` to not break the system python. This
despite the fact that the system python is fine, unless you use sudo pip
which is discouraged for separate reasons, and it is in fact quite
natural to install additional packages to the user site-packages.
It isn't even the job of the operating system to decide whether the user
site-packages is broken, whether the operating system gets the answer
correct or not -- it is the job of the operating system to decide
whether the operating system is broken, and that can be solved by e.g.
enforcing a shebang policy for distribution-packaged software, which
distros like Fedora do, and mandating not only that python shebangs do
not contain `/usr/bin/env`, but that they *do* contain -s.
Anyway, this entire kerfuffle is mostly just a bit of pointless
interactive churn, but it bites pretty hard for our use case, which is a
container image, so instead of failing to run because of theoretical
conflicts with the base system (we specifically need base system
integration...) we fail to run because 5 minutes into pulling homebrew
updates at the very beginning, pip refuses point-blank to work. I
especially do not know why it is the job of the operating system to
throw errors intended for interactive users at people designing system
integration containers who cannot "break" the system python anyway as it
is thrown away after every use.
Fix this by doing what homebrew should have done from the beginning, and
opting containers out of this questionable feature entirely.
This code cleverly tried to use a fancy new pathlib.Path method to get
the os.path.commonpath of two paths and check whether one is inside the
other. It failed pretty badly, because of a hidden secret of pathlib: it
is designed to throw random exceptions at all times (except when
building os.PathLike interfaces) instead of performing useful work.
Return to `os.path`.
In particular, before this change, we wanted to check if files are NOT
in a subpath of `preserve_path_from`, and raise a meson "ERROR: xxx" in
such a case. However, the code to check for it would raise a python
ValueError if that was the case, so we never got to the properly
formatted error.
Since we don't get a location for these errors, we can at least tell you
which targets you happen to be mixing together that produce this
problem.
Ran into while trying to debug a target mixing bug.
0e7fb07 introduced a subtile bug in the Python module.
If a python version is found, but is missing a required module,
it is added to the list of python installations, but the
`run_bytecompile` attribute for that version was not initialized.
Therefore, if any other python version added something to install, it
was raising a KeyError when trying to read the `run_bytecompile`
attribute for the python version with missing module.
Using scan-build gives the following warning:
"Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated."
This commit fixes this issue by adding the setup keyword to the meson command.
This allows using "--undefine __meson_verbose" to disable the verbose
mode. This is useful when running rpmbuild in an interactive terminal
and you don't want to be flooded with compilation outputs.
We also add --quiet to the meson install macro if __meson_verbose is
undefined to reduce the output generated by meson install.
The default output stays the same, the output is only affected if
__meson_verbose is explicitly undefined.
The .lcovrc file can contain several directives for genhtml, mostly
pertaining the visualisation of the generated HTML report. Passing the
config file to genhtml allows the user to customize their report.
Fixes#12863
The following workflows have been updated so that they are
triggered when the any of the test harnesses are updated:
macos,
os-comp,
msys2
Previously only changes to `run_unittests.py` caused these
workflows to be executed.
On Debian systems the cython compiler binary is installed as
`cython3`. The current logic for detecting whether to run the Cython
unit tests instead checks for `cython` or the value of the `CYTHON`
environment variable, which leads to cases where the underlying Meson
can correctly compile Cython code but the test harness excludes these
tests from execution because it cannot find `cython3`.
This commit makes the test harness use the same detection method as
Meson itself. It also takes the opportunity to refactor some existing
code which does the same job for Objective C and Objective C++ tests
to avoid repetition.
Special notes:
- _nvcc_arch_flags is always called with exact arguments, no need for
default values
- min_driver_version has its args annotation loosened because it has to
fit the constraints of the module interface?
The min_driver_version function has an extensive, informative custom
error message, so leave that in place.
The other two functions didn't have much information there, and it's
fairly evident that the cuda compiler itself is the best thing to have
here. Moreover, there was some fairly gnarly code to validate the
allowed values, which we can greatly simplify by uplifting the
typechecking parts to the dedicated decorators that are both really good
at it, and have nicely formatted error messages complete with reference
to the problematic functions.
It is pretty trivial and more confusing when standalone, especially the
use of a sentinel "unknown" string as a standin for "this isn't one of
the allowed object types". Much easier to directly raise an error in the
fallthrough/else.
L. E. Segovia
Tristan Partin
dragonmux
Karol Herbst
Charles Brunet
Sam James
Dylan Baker
Ole André Vadla Ravnås
Eli Schwartz
Eli Schwartz
Stephan Lachnit
Eisuke Kawashima
Daan De Meyer
Esther Dalhuisen
Andrew McNulty
Jouke Witteveen