Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to Meson's current master branch (1.4.99) #14

Merged
merged 869 commits into from
May 17, 2024

Conversation

rgommers
Copy link
Member

Merge with Meson's master branch at mesonbuild@7d28ff2. There were a fair few conflicts to resolve, but everything at numpy/numpy#26464 is green.

stephanlachnit and others added 30 commits February 19, 2024 09:12
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.
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.
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.
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.
Followup to commit 5c479d7.

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.
Since they do not implement a default install dir like BuildTargets do.

Fixes: mesonbuild#12843
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.
It returns `None | PackageDefinition`, not `PackageDefinition`
It's overwritten before it's ever read
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: mesonbuild#12869
…nd dist

These are all passed around interchangably inside Meson, so use a shared
protocol for them.
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
As putting them in the `properties` section is considered deprecated,
and Meson would then complain when trying to consume the resulting
machine file.
This was inherited from documentation of build target, but some sentences do not make sense in the context of the preprocessor.
Bindgen natively only considers .hpp to be C++ headers, but Meson
considers some additional extensions including .hh and .hxx to be C++.
We list other C++ header types in this list, so H should be included
This may be of particular use when a header is .h but should be treated
as a C++ header instead of a C header.
Especially for C++ this is very important.
Which should be `str | list[str]`, not `str | None`.
This allows us to ensure that the bindgen we're using is suitable for
our purpose.
Some text editors on Windows may use utf8bom encoding by default.
Prevent crash and properly report misencoded files.

Fixes mesonbuild#12766.
Followup to 7b7d2e0 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 mesonbuild#12648).

Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
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.
Midar and others added 27 commits April 28, 2024 03:14
This uses objfw-config to get to the flags, however, there's still
several todos that can only be addressed once dependencies can have
per-language flags.
OBJC=clang / OBJCXX=clang++ can pick up a newer Clang that no longer
supports bitcode.
…error

Previously, if a junked meson.build or native.ini was used we got a
lengthy traceback ending in UnicodeDecodeError.

Fixes: mesonbuild#13154
Fixes: mesonbuild#13156
Using the keyword argument dependencies with compiler.links() for vala doesn't work as the library being linked to needs to be prefixed with --pkg= before being passed to valac.
This is a similar commit to the one that added required to all the
compiler.has* functions.
We need the subdir of where the output file will actually be created,
not the current subdir of the interpreter.

Fixes: mesonbuild#13168
* In `CudaDependency._detect_language`, the first detected language is
  considered the linking one. Since `nvcc`/`cuda` implicitly know where the
  cuda dependency lives, this leads to situations where `cpp` as linking
  language is erroneously detected as `cuda` and then misses the `-L` argument.
When running our integration tests in systemd we depend on each test
having a unique name. This is always the case unless --repeat is used,
in which case multiple tests with the same name run concurrently which
causes issues when allocating resources that use the test name as the
identifier.

Let's set MESON_TEST_ITERATION to the current iteration of the test so
we can use $TEST_NAME-$TEST_ITERATION as our test identifiers which will
avoid these issues.
warning_level=0 is not 'none' but 'compiler default'.
@Plainname@ and @basename@ cannot be used in custom_target()
with multiple inputs. For those, similar macros are needed
with an index.

Fixes mesonbuild#13164
It is now getting uninstalled instead of updated, due to blockers on old
glib. In fact, we explicitly need it...
Basic support for TI Arm Clang toolchain
We changed the behavior in mesonbuild#6116 but did not change the docs as well.

Fixes mesonbuild#8233
@rgommers rgommers merged commit 31161ee into main-numpymeson May 17, 2024
5 of 39 checks passed
@rgommers rgommers deleted the update-may2024 branch May 17, 2024 07:26
@rgommers
Copy link
Member Author

Okay, this was happy in NumPy CI, and jobs here only had a few failures on rustc which is unrelated. So merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.