Skip to content

Don't rebuild c/cpp files that haven't changed since last build #257

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

Closed
cpearce opened this issue Oct 18, 2017 · 3 comments
Closed

Don't rebuild c/cpp files that haven't changed since last build #257

cpearce opened this issue Oct 18, 2017 · 3 comments

Comments

@cpearce
Copy link

cpearce commented Oct 18, 2017

We're using cc-rs in gecko-media and we've got enough files in our build now that a rebuild takes about a full minute now, which is pretty painful if you only changed one file. It would be awesome if cc-rs could automatically look in the target dir for previous builds and figure out what symbols haven't changed, and just relink the previous build's objects, rather than rebuilding every C/CPP file every single time.

@alexcrichton
Copy link
Member

Thanks for the report! I think this is a dupe of #230 so I'm going to close in favor of that.

@cpearce
Copy link
Author

cpearce commented Oct 18, 2017

I'm not sure it is the same as #230 though. Unless I'm mistaken, the re-run-if directives tell Cargo when to rerun the build script. If a build script re-runs, it reruns in its entirety, and the entire crate gets rebuilt.

What I want to happen is if the entire build script re-runs for whatever reason, cc-rs checks timestamps on headers/objects or whatever, and only rebuilds C/CPP files that have changed since the last build.

#230 is about detecting whether we should re-run the build script. This bug is about reducing what's rebuilt when we do rerun the build script.

@alexcrichton
Copy link
Member

It's true yeah, but #230 is sort of a prerequisite regardless?

I'd also imagine that if a C/C++ project is big enough to warrant features like this you'd probably want to use something like make/cmake? I'm not personally super keen on reimplementing a "worse make" ...

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

2 participants