Skip to content

fix: avoid rebuilding snarkOS binary every single time #3613

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

Open
wants to merge 1 commit into
base: staging
Choose a base branch
from

Conversation

joske
Copy link
Contributor

@joske joske commented Apr 28, 2025

Motivation

When you issue cargo run or even cargo test with no code changes at all, cargo would still re-build the snarkOS binary (and this can take a long time) on every single invocation. The cause for this is cargo:rerun-if-changed=., this line is not needed at all, and cargo will still notice when the code changes and rebuild as needed. With this line removed, you will no longer have a rebuild on every run. The cargo:rerun-if-changed= directive should only be used on extra things, like json schema's or generated code.

Test Plan

manually tested (and only build.rs changes)

@vicsn vicsn requested a review from Copilot April 28, 2025 12:31
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR removes the unnecessary "cargo:rerun-if-changed=." directive from build.rs to avoid rebuilding the snarkOS binary every time, thereby improving build performance.

  • Removed the "cargo:rerun-if-changed=." line, eliminating needless rebuild triggers.
  • Streamlined the build script to rely on Cargo's default change detection for code changes.

@kaimast
Copy link
Collaborator

kaimast commented May 17, 2025

I think this should be merged, as it would speed up the development process noticeably. That function in the build script does not actually change any source file and should not cause a recompile.

However, build.rs invokes the built crate to update the build information, which is shown in the CLI for example. There might be a reason we want to recreate the binary with updated build information even if nothing has changed. Maybe @raychu86 know if these rebuilds are intentional?

Also, with the fix, does a second run of cargo test still cause the code to recompile? If I understand correctly, the first run changes the build information and writes it to some source file, and on the second run cargo would detect the changed file and recompile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants