commit 6a8330af598753d5982a37933beeac2d6b565386: hpp was clearly meant
and used several times, just not in the release notes themelves.
commit a75ced6d50a3d479eda6dcdc9c3482493f2161f0: C/C++ "what"? We
mention the std in the commit, but not in the text of the release notes.
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.
Xavier Claessens
Eli Schwartz
L. E. Segovia
Ralf Gommers
Tristan Partin
dragonmux
Karol Herbst
Charles Brunet
Sam James
Dylan Baker
Ole André Vadla Ravnås
Eli Schwartz