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

prost-build triggers rebuild on arbitrary file change #139

Open
vorner opened this issue Nov 27, 2018 · 9 comments
Open

prost-build triggers rebuild on arbitrary file change #139

vorner opened this issue Nov 27, 2018 · 9 comments

Comments

@vorner
Copy link
Contributor

vorner commented Nov 27, 2018

Hello

Let's say I have some rust project and have done cargo build. Now I touch an arbitrary file around there, eg touch x. If I run cargo build now, it is very fast and mostly figures out it doesn't need to do anything.

However, this changes if I introduce prost-build into the project. Now the cargo build will rebuild the whole crate (and all the tests and other things if it is not cargo build but eg. cargo test --all).

My guess is, this has something to do with the fact that the file change provokes build.rs to be re-run. That one, in turn, overwrites the rs files generated from protobufs, which triggers the rebuild (even though the produced files are the same).

If my guess is correct, would it make sense to generate them to some temporary file first (eg. generated_file.rs.tmp), compare with the previous version (if present) and then move it into place only if it differs?

@vorner
Copy link
Contributor Author

vorner commented Dec 8, 2018

Hmm. That workaround doesn't seem to help :-(, must be something else.

@danburkert
Copy link
Collaborator

@vorner perhaps this todo is related? I admit I didn’t try and chase down the ‘correct’ way of handling this after punting and writing the todo.

@vorner
Copy link
Contributor Author

vorner commented Jan 8, 2019

It's most likely related to this, yes.

I tried to look through the cc repository, but it seems it contains no mention of rerun-if, so likely no, they don't have it figured out. On the other hand, cc is mostly used in -sys crates and these are not changed that often, so the motivation may be smaller there.

@hahseba
Copy link

hahseba commented Jan 15, 2019

I don't see what the problem indicated in the todo is. Shouldn't replacing the crate root be the goal here, because otherwise we'd still always rebuild? Also note that if other build scripts emit their own paths, prost currently doesn't rebuild if the .proto changes, which seems undesirable

@thomcc
Copy link

thomcc commented Jun 11, 2019

It seems like it's worth documenting this at the very least. AFAICT setting it has caused no problems for me (it's not like cargo no longer detects changes in src/blah.rs after setting it).

Not sure what you mean by it changes the crate root though.

@hahseba
Copy link

hahseba commented Jun 12, 2019

I was referring to the link to the todo comment above. I have used this feature manually in my program and have seen no problems with it, still definitely in favor of implementing this.

Timmmm added a commit to Timmmm/prost that referenced this issue Oct 14, 2019
This means things like cargo-watch work better. Fixes tokio-rs#139.
@Timmmm
Copy link
Contributor

Timmmm commented Oct 14, 2019

Sorry got my bug numbers wrong - it actually fixes #231 - not sure if it fixes this.

@dbrgn
Copy link
Contributor

dbrgn commented Oct 23, 2019

Shouldn't this solve the issue?

    println!("cargo:rerun-if-changed=proto/schema.proto");
    prost_build::compile_protos(&["proto/schema.proto"], &["proto/"]).unwrap();

@danburkert
Copy link
Collaborator

Shouldn't this solve the issue?

I think it should. I'd support adding an option to prost_build::Config to do that for each argument to compile_protos. It maybe should even be enabled by default. Would love if someone with more Cargo expertise could weigh in here, since I suspect there are subtleties at play.

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

No branches or pull requests

6 participants