forked from mesonbuild/meson
-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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
This is new as of 14.1.
* 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.
Bug: mesonbuild/pull/9453 Bug: mesonbuild/issues/9479#issuecomment-953485040
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
At commit 7d28ff2, 15 May 2024, version 1.4.99
Okay, this was happy in NumPy CI, and jobs here only had a few failures on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.