Allow subprojects to be built for both the build and host machine (2nd part) #15404
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 maps subproject name to version
Because it can be None, it is not possible to use PerMachineDefaultable.
Which de-duplicates a lot of printing material and makes it easier to change things.
Store it at construction time instead of extracting it from kwargs repeatedly. Extracted from a patch by Dylan Baker <dylan@pnwbakers.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Forcing the executor to the build machine doesn't actually work correctly once we allow build subprojects, but it also uses the wrong cmake_prefix_path.
Do not bother fully creating a new Build, since the environment will be overwritten anyway. Prefer setattr to __dict__ assignment. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Recursively copy the value if it is a collection; this ensures that values are not overwritten until merge() is called. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
stdlibs is a similar kind of cache to depenency_overrides, share it between build and host when not cross compiling. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Do not rummage into build.projects_args. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
All callers pass the subproject and machine of a target, move that to the callee. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This makes things easier to understand, with the project_args and project_link_args having the same structure as Build.global_args and Build.global_link_args. The difference is that the new member always includes an entry for the root project, so adjust those cases that need to look at subprojects only. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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
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.
Extracted from a patch by Dylan Baker <dylan@pnwbakers.com>
The builddir will not mirror the subdir in this case, and we need to track that.
…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. [Paolo: Rewritten Build.merge]
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.
Which is required to make test for installed files work correctly
bonzini
force-pushed
the
subproject-per-machine
branch
2 times, most recently
from
82a9dc4 to
f397d2a
Compare
Extracted from a patch by Dylan Baker <dylan@pnwbakers.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
bonzini
force-pushed
the
subproject-per-machine
branch
from
f397d2a to
45d036f
Compare
dnicolodi
reviewed
Dec 18, 2025
|
|
||
| Subprojects may now be built for the host or build machine (or both). This means | ||
| that build time dependencies can be built for the matching running the build in a | ||
| cross compile setup. When a subproject is run for the build machine it will act |
Member
There was a problem hiding this comment.
Something is off in this sentence.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Building on #15395, actually add the functionality needed to build subproject for both machines. This is also propagated recursively to dependencies and subprojects of
native: truesubprojects.Based on (and supersedes) #12258. Other than rebasing, the main logic changes are:
v.host is v.buildfor bulid-machine subprojectsBuildProjectclass added by Allow subprojects to be built for both the build and host machine (1st part) #15395)(name, for_machine)tuples in it. This makes it possible to present chains of subprojects more clearly asa-0.1:b-2.0 (build):c-3.0. Note that in such a scenarioc-3.0is technically built for the host machine ofb-2.0 (build)(which is the build machine ofa-0.1). This is handled correctly bycopy_for_build_machine()andPerMachine, but it messed up the old subproject stack handling.For now I've tested this on QEMU, by adding
native: trueto all subprojects linked to Rust procedural macro crates (such asproc_macro2,quote,syn) and removing it from the crates'static_libraryinvocations. All crates can find their dependencies correctly and there are no warnings about cross compilation breakage, including those that are only depended upon indirectly.It certainly can be stressed a bit more, so I'm leaving it as draft for now.