Stream: t-compiler

Topic: x.py vs branches


matklad (May 13 2019 at 06:34, on Zulip):

What is the best workflow for working with several branches in the compiler, that avoids rebuilds?

My understanding is that, if you have two branches with different bases, switching between the two and building stuff will constantly re-build a lot of stuff because of changes at the base.

I work-around it by having two instances of rust-lang/rust checked out locally, but that is suboptimal.

Is there some way to tell x.py/Cargo to mix branch name into artifact hash?

davidtwco (May 13 2019 at 07:26, on Zulip):

I don’t know of a way to make changing branches not require a full build.

I have some local tooling built around keeping a bunch of working directories locally.

I only reuse a directory once the PR that I was working on in it has been merged or closed. The tooling automates the creating of new directories (cloning, symlink my config.toml, clean, build), keeping track of what directories are assigned to what and tidying up after me. I’ve got a cron job that uses the tool to update all the unassigned directories so they have a build of the latest master each night. I can just ask it for a directory to work on X, it keeps track of that, gives me a directory that’s already built and I know I’m at most 24 hours behind master.

detrumi (May 13 2019 at 07:34, on Zulip):

Someone mentioned before that you could use git workspaces for that, but I'm not sure how that works exactly

davidtwco (May 13 2019 at 08:22, on Zulip):

I haven't heard of git-workspace, only git-worktree. I can't find anything other than an npm package for git-workspace.

My understanding of git-worktree is that it supports multiple working trees attached to a single repository, saving space as it deduplicates all of the data in the history and stuff like that. I want to add support for that to my tool, I just didn't know it existed when I wrote it.

They both do slightly different things. Using just git-worktree will avoid having multiple clones, but it won't make sure that you have full builds of any of your working trees available and up-to-date. For example, if you made a new worktree with git worktree add then you would still need to run x.py build in that new folder to use it. I'd like to eventually use them together, so that my tool creates the working directories using git-worktree and then keeps them up-to-date and assigns them tasks.

nikomatsakis (May 13 2019 at 17:38, on Zulip):

Personally I just keep 9 checkouts

nikomatsakis (May 13 2019 at 17:38, on Zulip):

:)

oli (May 13 2019 at 17:48, on Zulip):

@davidtwco 's workman tool manages my (ever increasing number of) checkouts: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/working.20directory.20management/near/160277023

davidtwco (May 13 2019 at 17:49, on Zulip):

@oli was kind enough to contribute some features earlier in the week too.

davidtwco (May 13 2019 at 17:50, on Zulip):

I also use it to have a working directory that it’ll never assign for me to use but will keep up to date which is built without any optimisations. It’s slow but it works well with a debugger so I sometimes jump to that directory to understand what master is doing better when working on a PR, which has been helpful.

Last update: Nov 22 2019 at 04:35UTC