Building without remote_server #100

ekliot commented 2026年03月13日 18:08:13 +01:00

I've been poking around the build process, and noticed that remote_server takes a long time to compile (took me ~15min out of ~60min).

I'm assuming that remote_server is used for zed's collaboration features, which I'm not planning to use, and as far as I can tell are currently unused in gram?

If that's true, I think it would be helpful to:

• make building remote_server opt-in as part of the build scripts
  • this ought to speed up local builds
• adjust CI to build gram and remote_server as separate releases
  • this ought to parallelize the runners, and to allow downloading releases without remote_server
• more clearly delineate the role remote_server has in gram

If I'm wrong in my assumption, and/or misunderstanding rust build processes (as in, gram and remote_server cannot be built separately), please let me know.

(grepping for remote_server gives the impression just ripping it out would be a little messy, hence suggesting a bandaid fix to simply not build the binary, for now)

I've been poking around the build process, and noticed that `remote_server` takes a long time to compile (took me ~15min out of ~60min). I'm _assuming_ that `remote_server` is used for zed's collaboration features, which I'm not planning to use, and as far as I can tell are currently unused in gram? If that's true, I think it would be helpful to: - make building `remote_server` opt-in as part of the build scripts - this ought to speed up local builds - adjust CI to build `gram` and `remote_server` as separate releases - this ought to parallelize the runners, and to allow downloading releases without `remote_server` - more clearly delineate the role `remote_server` has in `gram` If I'm wrong in my assumption, and/or misunderstanding rust build processes (as in, `gram` and `remote_server` cannot be built separately), please let me know. (grepping for `remote_server` gives the impression just ripping it out would be a little messy, hence suggesting a bandaid fix to simply not build the binary, for now)

theDoctor commented 2026年03月13日 18:34:36 +01:00

I think there is a misunderstanding. As I understand, gram does not have support for any of the collaborative stuff that Zed has at all. remote_server is concerned with developing on a remote machine using gram.

I think there is a misunderstanding. As I understand, `gram` does not have support for any of the collaborative stuff that Zed has at all. `remote_server` is concerned with developing on a remote machine using `gram`.

ekliot commented 2026年03月13日 18:45:36 +01:00

ah, gotcha, thank you for clarifying.

to clarify further, is remote_server used by the client, or is it the server that clients connect to?

ah, gotcha, thank you for clarifying. to clarify further, is `remote_server` used by the client, or is it the server that clients connect to?

theDoctor commented 2026年03月13日 19:23:16 +01:00

I think it's the latter, have you looked at the docs here? Maybe this will answer your question.

I think it's the latter, have you looked at the docs [here](https://gram.liten.app/docs/remote-development/)? Maybe this will answer your question.

krig commented 2026年03月13日 22:46:47 +01:00

The remote_server is a binary that you copy to a remote host and the editor starts and talks to, to edit projects on that host via SSH. It doesn’t have anything to do with collaboration.

But yeah it is only used for that purpose. We could add a build option to skip building it, yes

The remote_server is a binary that you copy to a remote host and the editor starts and talks to, to edit projects on that host via SSH. It doesn’t have anything to do with collaboration. But yeah it is only used for that purpose. We could add a build option to skip building it, yes

ekliot commented 2026年03月14日 18:24:31 +01:00

ah, thanks @theDoctor, those docs are helpful! I missed that.

if there's a clear line between "client" builds and "host" builds, then I guess my more precise issue is it would be convenient to be able to build one or the other (and by extension, to have separate tarballs in the CI artifacts).

I can dig into that, time permitting, my rust-fu is lacking but I think this should be more of a CI/build process task.

ah, thanks @theDoctor, those docs are helpful! I missed that. if there's a clear line between "client" builds and "host" builds, then I guess my more precise issue is it would be convenient to be able to build one or the other (and by extension, to have separate tarballs in the CI artifacts). I can dig into that, time permitting, my rust-fu is lacking but I think this should be more of a CI/build process task.

krig commented 2026年05月14日 23:34:51 +02:00

You can build the remote server only by running cargo build -p remote_server. That will build it for your current platform, but building it for another target and using musl for example is not hard once you've figured out the target triplet for your target platform.

You can build the remote server only by running `cargo build -p remote_server`. That will build it for your current platform, but building it for another target and using musl for example is not hard once you've figured out the target triplet for your target platform.