The recommended computers for Gecko engineers today involve a very beefy desktop, and a less-powerful laptop computer. This is a good model when it comes to value per dollar because it's much cheaper to get high computational power in a desktop than in a laptop. This system encourages use of the lightweight low-power laptop as a coding device, as it is portable and easy to bring to conferences etc. while using the desktop to perform the expensive & slow gecko builds. Unfortunately our support for this pattern in our build tooling right now isn't super well fleshed out. It would be awesome if we could put some time and energy into making this workflow which we're trying to encourage within the company smoother. This is the setup I've been using for the past few months: 1. I have a local checkout of mozilla-central on my laptop 2. I make code changes on my local computer using my graphical text editor of choice, and manage version control work such as rebases and clones locally. This makes editing code smooth & low latency. 3. I use `lsyncd` to synchronize the source directory, ignoring object directories or similar, over to my desktop computer. This uses a filesystem watching API to be notified when one of the files I'm syncing changes, and uses a ssh connection to perform the update on the remote computer. 4. When I want to build, I ssh into the remote machine, and run `./mach build` in the target directory. This builds the code on the remote machine. I don't try to sync the object directory back down, as it is multiple gigabytes in size. 5. I run any tests which I need to run in a VNC session, from ssh, which I connect to with a VNC client from my laptop. This works decently well for most development. I get to have a portable computer which I work from, while I do my builds on a very beefy desktop. Unfortunately it has a few downsides: 1. If I run a test which updates a file on the remote machine, such as `mach web-platform-tests --update-manifest` (or whatever that command is), I have to remember to manually scp the changed file back to the laptop & check the changes in. 2. This is also the case if I ever need to recompute the Cargo.lock files or re-vendor our third party dependencies for rust code. 3. There's no good way for me to send the built binaries back to my local machine if I want to perform tests on them locally & no good way for me to run mochitests on a bundled executable if I make one. 4. I have to manually set up annoying things such as the lsyncd setup, and remember to manage them correctly as my needs change. 5. I don't have headers or similar stuff set up locally, so I can't use code completion or other nice editor features. 6. If I'm not in the office, connecting through the mozilla VPN is really, really slow, which makes it hard to be efficient when working from home or when at a work-week or all hands. I feel like there's some solution here where we could improve our tooling to the point where we can work on a low-power laptop with an internet connection, when building push our code changes out to a remote machine, have that machine build executables, and then send them back. Ideally tools like mach should be able to work on one of these bundled executables without the full source directory present.
Somewhere there's a very old bug or document where I outlined a solution to this in the form of `mach environment` which does many of the things you've described. Magic "rsync" is the crux of the solution.
You need to log in before you can comment on or make changes to this bug.