Skip to content

Use DEPS file for checking out third party code.#2345

Closed
dj2 wants to merge 1 commit intoKhronosGroup:masterfrom
dj2:deps
Closed

Use DEPS file for checking out third party code.#2345
dj2 wants to merge 1 commit intoKhronosGroup:masterfrom
dj2:deps

Conversation

@dj2
Copy link
Copy Markdown
Collaborator

@dj2 dj2 commented Jan 29, 2019

This CL simplifies the DEPS file in SPIRV-Tools and removes all the Chrome stuff. The git-sync-deps script is also added which allows using the DEPS file and script to handle all the bot updates. The README.md is updated to make this the preferred way of syncing the external dependencies.

@dj2
Copy link
Copy Markdown
Collaborator Author

dj2 commented Jan 29, 2019

Thoughts everyone?

Copy link
Copy Markdown
Contributor

@zoddicus zoddicus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I think other people should take a look at it and approve before merging.

@s-perron
Copy link
Copy Markdown
Collaborator

I don't think I like this. We are not living at head anymore. The smoke test was specifically meant to be an early warning that the latest glslang does not work with the latest spirv-tools. That has now been pegged to a specific version of glslang.

I don't like the idea of the builds using the DEPS file. We want to always test with the latest. This way we know as soon as possible that something is broken. It has not created much of a problem for us because we do not have many dependencies.

I also don't like the responsibility of updating the DEPS file. It is not clear who will do that and when.

@dj2
Copy link
Copy Markdown
Collaborator Author

dj2 commented Jan 29, 2019

I think I mis-understood the smoketest. I thought, in this case, it was checking that current shaderc builds with the version of spirv-tools being committed? Is it checking both shaderc and glslang?

We've run into a few issues where we've had to peg re2 or googletest to specific revisions. The main benefit I see to the DEPS file is that the build is repeatable. You know all the bots built at the same version and you know what those revisions are. With the current system, I have no idea when the last green spriv-tools and spirv-headers as as spirv-headers could have been rolled but no bots triggered in spirv-tools.

The DEPS get rolled as needed. If you want to pull in new spirv-headers features into spirv-tools, roll deps. For googletest, re2 and effcee, we roll as needed.

@dj2
Copy link
Copy Markdown
Collaborator Author

dj2 commented Jan 29, 2019

Speaking of, the deps for re2 and effcee need to be rolled in the DEPS file to make windows pass, heh.

@fjhenigman
Copy link
Copy Markdown
Contributor

I can't see why we wouldn't want this. No surprise breakages to be investigated. Green bots so we can land CLs. Known good configurations for users.

@fjhenigman
Copy link
Copy Markdown
Contributor

If it's really important to catch breakage as early as possible, we could add a bot that builds with everything at ToT. Then whoever cares can monitor that bot.

@s-perron
Copy link
Copy Markdown
Collaborator

At the very least we have to leave the smoketest with the latest from every component. If we do that, then that test can catch any failures early, and we will all see it. It is not hidden away where nobody sees it like the asan test for shaderc were.

@dj2
Copy link
Copy Markdown
Collaborator Author

dj2 commented May 28, 2019

Closing this for now. We can re-open when we investigate getting auto-rolls up for the dependencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants