Skip to content
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

Compile to a monolithic binary #1504

Closed
ishitatsuyuki opened this issue Sep 28, 2018 · 1 comment · Fixed by #3011
Closed

Compile to a monolithic binary #1504

ishitatsuyuki opened this issue Sep 28, 2018 · 1 comment · Fixed by #3011
Labels
A-backend ⚙️ C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear

Comments

@ishitatsuyuki
Copy link
Contributor

This project is currently in the structure of a gigantic library plus a few manage commands.

The issue is that the binaries are very fat and having multiple of them eats up disk space quickly. libcargo_registry on debug build takes over 100MB on its own, and it's linked to 8 different binaries. My target directory is easily over 2GB.

Also, this approach is no good for deployment as well. It leads to larger uploaded bundle, although gzip should help here.

Instead, we should have one monolithic binary and handle all the subcommands with clap. As a random note, Clap 3.x in development allows more modular code because it removes the facade between App and Subcommand.

@carols10cents carols10cents added A-backend ⚙️ C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear labels Nov 11, 2019
@jtgeibel
Copy link
Member

I think consolidating into two binaries (maybe server and ops) would be a good goal, though we can make incremental progress by combining just a few binaries at a time.

Right now, when running cargo test: lib.rs, all binaries, and all.rs are built in both debug and test profiles. (Cargo assumes that tests may exec any binary, so regular binaries are build in addition to the test binaries.) None of our binaries include tests so this is a lot of extra build time that doesn't add useful feedback to the development cycle.

Even when linking with lld via RUSTFLAGS="-C link-arg=-fuse-ld=lld", all this extra linking adds to the build time.

By consolidating into fewer binaries, it should improve build time and RAM consumption during local development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-backend ⚙️ C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants