-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[build-script] Introduce ProductBuilder. Transform Ninja to use it. #23822
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
[build-script] Introduce ProductBuilder. Transform Ninja to use it. #23822
Conversation
source_dir=self.workspace.source_dir("ninja"), | ||
build_dir=self.workspace.build_dir("build", "ninja")) | ||
workspace=self.workspace, | ||
host=StdlibDeploymentTarget.get_target_for_name( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of this is your doing, I'm wondering if you know the history. Why is this in StdlibDeploymentTarget
? Why is this being built for the host_target
and not build_target
? This is the tool being built for the build right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think StdlibDeploymentTarget
is a little misnamed at this point, because it is used for more things that just the stdlib. If you think about it as CompilationTarget
or DeploymentTarget
is easier to understand.
Ninja is build only for the machine building the rest of the pieces (it is build if it cannot be found in the toolchain/path), so it is fine to “hardcode” here to host_target
(which is the current machine).
If you look at the implementation of make_builder
, it actually ignores the target. The previous implementation didn’t care about the target (so it builds for the local target).
PD: there's a big mess of names in the build script. Sometimes host
refers to the device that run the code (arguments --host-test
and --skip-test-ios-host
which control to run or not tests on the external devices), but sometimes refers to the machine doing the build (like this host_target
and arguments like --build-runtime-with-host-compiler
and --host-cc
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I figured it was a poorly named variable at this point. I was thinking of it as TargetInformation
. I was wondering if you knew why this had come to be poorly named at this point.
As to the Ninja bits, right - its again a name thing. target
is the target where generated code will be run, host
is where the generated code generator will run, and build
is the machine where the build is occurring. These are well documented names, so it was a question of does the current machinery not name things accordingly?
I think that making it deal with cross-compilation is great thing, but way outside the scope of this current change .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the renaming, from comments and clues in the code, I think there was a previous try to make everything more standard, but it was necessary to keep the argument names the same for compatibility, which probably makes things a little bit more complicated. I can see if something can be done as a cleanup when all these pieces fall into place (I prefer to have the “wrong” names, since they match better what the build-script-impl
have).
@swift-ci please test |
Build failed |
Build failed |
utils/swift_build_support/swift_build_support/products/product_builder.py
Outdated
Show resolved
Hide resolved
utils/swift_build_support/swift_build_support/products/ninja.py
Outdated
Show resolved
Hide resolved
utils/swift_build_support/swift_build_support/products/ninja.py
Outdated
Show resolved
Hide resolved
29159b9
to
a353096
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed a couple of points pointed out by Ross, and also removed the linter problem pointed out by CI.
utils/swift_build_support/swift_build_support/products/ninja.py
Outdated
Show resolved
Hide resolved
utils/swift_build_support/swift_build_support/products/product_builder.py
Outdated
Show resolved
Hide resolved
@swift-ci please test |
Build failed |
As proposed in swiftlang#23822, the do_* methods should only be using the * parts. Because all building should have the same names, this commit removes the prefix from all the method instances.
a353096
to
e5eac33
Compare
Removed the PD: the test were green before I pushed again. |
@swift-ci please smoke test |
fd406cd
to
9ac1b7a
Compare
Moved the initializer into the formal requirements of the |
@swift-ci please smoke test |
The failures seems to be related to #23980, which disables those tests completely. |
9ac1b7a
to
1ee8a04
Compare
@swift-ci please test |
Build failed |
@Rostepher, @compnerd: I would like to restart my efforts in these PRs, if everyone is onboard. Without this PR and some of the others I am a little bit blocked about the next steps. If there's further feedback or requests, it would be my pleasure to make the changes. (PD: other people can also provide feedback) |
First and foremost, thank for all the work done in this PRs and the rest of the project. We know that we are all very busy, but it would be great to know if the radio silence is because we are busy or something related to the PRs contents. If the PRs conflict with internal systems and modifications, I would not mind modifying this to adapt better (or help modifying the internal systems if that's possible), but without any clue of what can be modified, I cannot do that much. Thanks, and sorry for insisting again. |
utils/swift_build_support/swift_build_support/products/product_builder.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback. I will change a couple of things and resubmit.
utils/swift_build_support/swift_build_support/products/product_builder.py
Outdated
Show resolved
Hide resolved
ProductBuilder allows us to tackle the different way than the different products need to be build. The builders follow a very simple interface, but inside them the details are hidden. Previously the Ninja product was both a Product and ProductBuilder. The methods that did the build have moved into ProductBuilder to match the future ProductBuilders.
1ee8a04
to
5c0e743
Compare
@swift-ci please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm satisfied with these changes now.
ProductBuilder
allows us to tackle the different way than the differentproducts need to be build. The builders follow a very simple interface,
but inside them the details are hidden.
Previously the Ninja product was both a
Product
and also the process to build Ninja. Themethods that did the build have moved into
ProductBuilder
to match thefuture
ProductBuilders
.Product
andProductBuilder
are very close, but the current design ofProduct
is not adequate to compile for different hosts and lacks of some access to other parts of the script. Instead of modifyingProduct
, I decided to keep separate from it to allow the rest of the script to keep working the same (it will also allow to keep the previous way of doing things and the new way of doing things in parallel, which might made the migration less scary).Pieces that
ProductBuilder
requires, but weren’t available inProduct
are the target host and the workspace information. The first is needed to generate the right parameters to invoke CMake and other build scripts, while the second is necessary to find out about other product locations (Swift product references LLVM, LLDB references both Swift and LLVM), as well as allowing access to the build results for the current target, and also the tools host target.Later commits will show how
ProductBuilder
is leveraged to invoke different building scripts and how flexible is the setup.This was part of #23257. I’m trying to split the PR in smaller ones to make the reviews easier. Other PRs in this group are #23303, #23803, and #23810 .
/cc @compnerd