Skip to content

[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

Merged

Conversation

drodriguez
Copy link
Contributor

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 also the process to build Ninja. The
methods that did the build have moved into ProductBuilder to match the
future ProductBuilders.

Product and ProductBuilder are very close, but the current design of Product is not adequate to compile for different hosts and lacks of some access to other parts of the script. Instead of modifying Product, 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 in Product 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

source_dir=self.workspace.source_dir("ninja"),
build_dir=self.workspace.build_dir("build", "ninja"))
workspace=self.workspace,
host=StdlibDeploymentTarget.get_target_for_name(
Copy link
Member

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?

Copy link
Contributor Author

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).

Copy link
Member

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 .

Copy link
Contributor Author

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).

@compnerd
Copy link
Member

compnerd commented Apr 6, 2019

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Apr 6, 2019

Build failed
Swift Test OS X Platform
Git Sha - 29159b9cc513a0d46ea3a5aeba7eabde4d691880

@swift-ci
Copy link
Contributor

swift-ci commented Apr 6, 2019

Build failed
Swift Test Linux Platform
Git Sha - 29159b9cc513a0d46ea3a5aeba7eabde4d691880

@drodriguez drodriguez force-pushed the build-script-product-builder-ninja branch from 29159b9 to a353096 Compare April 6, 2019 20:50
Copy link
Contributor Author

@drodriguez drodriguez left a 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.

@compnerd
Copy link
Member

compnerd commented Apr 7, 2019

@swift-ci please test

@swift-ci
Copy link
Contributor

swift-ci commented Apr 7, 2019

Build failed
Swift Test Linux Platform
Git Sha - 29159b9cc513a0d46ea3a5aeba7eabde4d691880

drodriguez added a commit to drodriguez/swift that referenced this pull request Apr 8, 2019
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.
@drodriguez drodriguez force-pushed the build-script-product-builder-ninja branch from a353096 to e5eac33 Compare April 9, 2019 00:28
@drodriguez
Copy link
Contributor Author

Removed the do_ from this PR, as I did in #23871. No other changes at the moment.

PD: the test were green before I pushed again.

@Rostepher
Copy link
Contributor

@swift-ci please smoke test

@drodriguez drodriguez force-pushed the build-script-product-builder-ninja branch 2 times, most recently from fd406cd to 9ac1b7a Compare April 9, 2019 18:44
@drodriguez
Copy link
Contributor Author

Moved the initializer into the formal requirements of the ProductBuilder. It looks a little bit out of place for single product builders, but I hope it will not create problems later.

@compnerd
Copy link
Member

@swift-ci please smoke test

@drodriguez
Copy link
Contributor Author

The failures seems to be related to #23980, which disables those tests completely.

@drodriguez
Copy link
Contributor Author

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 1ee8a0482daeef8394e41e72f30bdc92b53addb5

@drodriguez
Copy link
Contributor Author

The Linux failure seems to be fixed in #24372.

@swift-ci please test linux platform

@drodriguez
Copy link
Contributor Author

@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)

@drodriguez
Copy link
Contributor Author

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.

Copy link
Contributor Author

@drodriguez drodriguez left a 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.

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.
@drodriguez drodriguez force-pushed the build-script-product-builder-ninja branch from 1ee8a04 to 5c0e743 Compare May 13, 2019 19:53
@drodriguez
Copy link
Contributor Author

@swift-ci please test

@Rostepher Rostepher self-requested a review May 14, 2019 00:02
Copy link
Contributor

@Rostepher Rostepher left a 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.

@drodriguez drodriguez merged commit 0de91dc into swiftlang:master May 14, 2019
@drodriguez drodriguez deleted the build-script-product-builder-ninja branch May 14, 2019 18:56
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.

4 participants