Allow subprojects to be built for both the build and host machine #12994
+873
−302
Conversation
This file contains hidden or 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
Which is required to make test for installed files work correctly
Which de-duplicates a lot of printing material and makes it easier to change things.
forcing the executor to the build machine doesn't actually work correctly once we allow build subprojects.
Which maps subproject name to version
Currently, the assumption is that a subproject will only be built for the host machine. Instead back the storage with PerMachine objects, which fixes this. This goal of this patch is to extend the storage, not enable per-machine subprojects yet. This uncovers some cases where we should be using the SubProject type, but instead are using a string.
The builddir will not mirror the subdir in this case, and we need to track that.
We need this information later to build both a build and a host subproject separately. It's a lot of boilerplate and has been split out to try to simplify review of the difficult pieces
When a subproject is built for both machines, we need to ensure that the outputs don't clash. To do this we'll put the outputs of build only subprojects in a separate root folder (build.subprojects/). We need special methods for this. Currently, this patch changes nothing in the output, but as more boilerplate kind of code it's been split out.
…ild == host config In order to run a build machine only subproject, we create a new Build, Environment, and CoreData object that have look like a host == build configuration, but that are properly merged back into the originals.
The current situation in Meson is that subprojects are always built for the host machine. This means that while cross compiling, a tool that must be run on the build machine must have all of its dependencies met by the system (pkg-config, cmake, config-tool, etc); but dependencies for the host machine can be built. With this patch subprojects may also be built for the build machine. Nothing should ever be installed from a subproject for the build machine, while cross compiling. However, we we are not cross compiling they are installed, since Meson can't really tell the difference between a host and build dependency.
For the most part, what we had before would work correctly for cross building. There is, however a case where this might not work correctly, which is a project for the host machine that builds a build machine target and uses that as an override (think some kind of transpiler), to make this work correctly we need to add a native keyword argument to the `override_find_program` method.
We will be needing it there to deal with options, and in IntrospectionInterpreter, where there is no Build object.
The subproject shares the PerMachine instance with us, so there's no need to synchronize it.
As self.subprojects is shared state.
Even if it's the host machine from the perspective of the subproject, it looks confusing when a dependency lookup happening shortly afterwards results in logging that refers to the build machine.
It's not really that useful anyway, so not worth dealing with subproject summary collisions between build and host.
Mainly to avoid clashes in meson-uninstalled, but also since we don't want to install any .pc files.
The added colon was presumably unintentional, as the message already has one near the end, so it ended up slightly clunky to read.
Adjusting the regular expressions to match the new output, where we now also log the machine each dependency is for.
oleavr
force-pushed
the
submit/subproject-per-machine
branch
from
10c453d to
cc689ed
Compare
Latest MSYS2 provides LLVM 18, where its CMake files are no longer broken. This reverts commit 890dd31.
7e2eed64ea4b489234417497c13520d8634fe849 is the first bad commit
commit 7e2eed64ea4b489234417497c13520d8634fe849
Author: Ole André Vadla Ravnås <[email protected]>
Date: Fri Mar 15 23:56:28 2024 +0100
interpreter: Fix builddir path logic for is_build_only
mesonbuild/interpreter/interpreter.py | 30 +++++++++++++++++++++---------
mesonbuild/interpreter/mesonmain.py | 5 ++---
2 files changed, 23 insertions(+), 12 deletions(-)breaks setup of a subproject reproduction https://github.com/fruzitent/meson-pr-12994-bug |
|
Any chance this PR might make it into the next release? It fixes a very annoying limitation (not being able to wrap native dependencies when cross compiling). |
Co-authored-by: Håvard Sørbø <[email protected]>
|
No. Before we can land this we really need to the interpreter refactor I did that is way too big to go into the next release. I will be pushing for that in 1.7 |
|
@dcbaker what is the "interpreter refactor"? I don't think this would be enough for #14952, because Rust crates can have different feature sets for the build and host machines. However, if this series lets you |
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.
This is a continuation of #12258, rebased on latest master, with some patches added on top. It now works well enough that I can't find any more issues when building frida-core with it 🎉
/cc @dcbaker