-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
x.py dist
builds tools twice due to dependency vendoring?
#93033
Comments
Commenting out the Line 498 in 9ad5d82
|
@matthiaskrgr Can you show which jobs are building tools multiple times? The only one I know of is dist-x86_64-apple due to #90100. I don't think that is related to PlainSourceTarball, since dist-x86_64-apple does not build that step. I am looking at dist-x86_64-linux, and it is building cargo twice (once as a tool, and once for RLS). There's a check that is supposed to prevent that, so I'm curious why that is happening. |
I determined why I'm uncertain how to fix that. I'll need to think about it. |
Oh then we talked about two different issues probably 😅 So when cargo is being built, it gets its own commithash from the rls repo, but then when we built cargo again as rls dependency, the commithash comes from the rls repo and we build both cargo (again, since hash changed) and rls with the commit hash from the rls repo? Perhaps we can hack around like: |
…arball, r=Mark-Simulacrum build: dist: defer PlainSourceTarball Apparently it changes some tool sources and invalidates their fingerprints, forcing us to build them several times (before and after vendoring sources). I have not dug into why vendoring actually invalidates the figreprints, but moving the vendoring lower in the pipeline seems to avoid the issue. I could imagine that we somehow write a .cargo/config somewhere which somehow makes subsequent builds use the vendored deps but I was not able to find anything. I checked the sizes of generated archives pre and post patch and their are the same, so I hope there is no functional change. Fixes rust-lang#93033
I have posted rust-lang/cargo#10323 to fix the issue with cargo and rls. That should help shave a minute or two on the dist builders. I'm still planning on looking at the issues with #90100. |
There is this problem that
x.py dist
builds most of the tools twice.It seems that during the initial build (which is the same as
x.py build
) we take the normal sources from$CARGO_HOME
, but then there is some dependency vendoring taking place which seems to override some of the dependency paths to the vendored ones.This causes fingerprints to change and some of the tools to be rebuilt:
The text was updated successfully, but these errors were encountered: