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

is rerun_file necessary? #139

Closed
dingelish opened this issue Oct 31, 2019 · 6 comments · Fixed by #140
Closed

is rerun_file necessary? #139

dingelish opened this issue Oct 31, 2019 · 6 comments · Fixed by #140
Labels

Comments

@dingelish
Copy link
Contributor

autocfg::rerun_path(file!());

Hi there,

I'm really curious how rerun_path(file!()); works. I've never seen it works. When do we need it? Thanks!

@cuviper
Copy link
Member

cuviper commented Oct 31, 2019

autocfg::rerun_path outputs cargo:rerun-if-changed=PATH, and here PATH is the current source file name given by file!(). As described in the cargo docs:

  • rerun-if-changed=PATH is a path to a file or directory which indicates that the build script should be re-run if it changes (detected by a more-recent last-modified timestamp on the file). Normally build scripts are re-run if any file inside the crate root changes, but this can be used to scope changes to just a small set of files. (If this path points to a directory the entire directory will not be traversed for changes -- only changes to the timestamp of the directory itself (which corresponds to some types of changes within the directory, depending on platform) will trigger a rebuild. To request a re-run on any changes within an entire directory, print a line for the directory and another line for everything inside it, recursively.) Note that if the build script itself (or one of its dependencies) changes, then it's rebuilt and rerun unconditionally, so cargo:rerun-if-changed=build.rs is almost always redundant (unless you want to ignore changes in all other files except for `build.rs).

So it's really that final note we're applying here -- the build script's own source is the only thing that needs to trigger rerunning itself, at least for num-traits.

It doesn't really matter when depending on this crate, as none of the crate sources will ever be modified, but it's useful in development to reduce the build time.

@dingelish
Copy link
Contributor Author

Thank you so much for the explanation!

Our project is now using --remap-path-prefix to erase the path info and make the generated binaries deterministic, no matter where the source code is. Without the remap, the output of build.rs is

cargo:rerun-if-changed=/home/ding/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/num-traits-0.2.8/build.rs

After we enable a rustc flag --remap-path-prefix=${HOME}/.cargo=/cargo_home, the output is:

cargo:rerun-if-changed=/cargo_home/registry/src/git.luolix.top-1ecc6299db9ec823/num-traits-0.2.8/build.rs

/cargo_home is not exist so it seems that cargo cannot judge if the file has a newer timestamp or not, which makes num-traits compiled every time. We wonder if this is a "feature" or "bug" of cargo? or is there anything we can do to reduce the build time?

@cuviper
Copy link
Member

cuviper commented Nov 1, 2019

Oh, I never thought about --remap-path-prefix, but I suppose it's logical that this would affect file!() too. We should probably change this to a simpler rerun_path("build.rs").

@dingelish
Copy link
Contributor Author

That will be great! Thank you! Could I submit a PR?

@cuviper
Copy link
Member

cuviper commented Nov 2, 2019

Sure, a PR is welcome. We should do this across all num crates, and adjust the example given in autocfg too, but it's up to you if you want to be so ambitious. 🙂

@dingelish
Copy link
Contributor Author

I'm glad to help with all of them :-)

@bors bors bot closed this as completed in da66427 Nov 2, 2019
@bors bors bot closed this as completed in #140 Nov 2, 2019
bors bot added a commit to rust-num/num-bigint that referenced this issue Nov 6, 2019
116: Compatible with cargo --remap-path-prefix r=cuviper a=dingelish

As discussed in [num-traits issue 139](rust-num/num-traits#139).

Co-authored-by: Yu Ding <dingelish@gmail.com>
bors bot added a commit to rust-num/num-complex that referenced this issue Nov 6, 2019
67: Compatible with cargo --remap-path-prefix r=cuviper a=dingelish

As discussed in [num-traits issue 139](rust-num/num-traits#139).

Co-authored-by: Yu Ding <dingelish@gmail.com>
bors bot added a commit to rust-num/num-integer that referenced this issue Nov 6, 2019
27: Compatible with cargo --remap-path-prefix r=cuviper a=dingelish

As discussed in [num-traits issue 139](rust-num/num-traits#139).

Co-authored-by: Yu Ding <dingelish@gmail.com>
bors bot added a commit to rust-num/num-rational that referenced this issue Nov 6, 2019
60: Compatible with cargo --remap-path-prefix r=cuviper a=dingelish

As discussed in [num-traits issue 139](rust-num/num-traits#139).

Co-authored-by: Yu Ding <dingelish@gmail.com>
bors bot added a commit to rust-num/num-iter that referenced this issue Nov 6, 2019
12: Compatible with cargo --remap-path-prefix r=cuviper a=dingelish

As discussed in [num-traits issue 139](rust-num/num-traits#139).

Co-authored-by: Yu Ding <dingelish@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants