rustc should open the output file as soon as it starts compiling

[sethfowler]

Consider the following sequence of actions:

• I run make, which runs rustc.
• I update a source file while rustc is compiling.
• rustc finishes compiling.

What I expect is that, if I run make again, the changes will get detected and rustc will be invoked again. What actually happens is that make reports that there's nothing to be done.

This is probably because rustc is waiting way too long to open the output file, so updates to source files while the compiler's running appear to "happen before" the output file from make's point of view.

[brson]

Although this makes sense to me, it may not be causing the behavior you are seeing now. The library build dependencies are mostly driven by a bunch of 0-byte dummy files that the makefiles touch after each build step. The reason for this is that the names of libraries output by rustc are not stable (they contain a hash of the metadata).

Assuming that we fixed that problem though, implementing this still seems problematic since the final artifact is generated by the linker, not rustc itself. If we were to touch the .so files before building, we would need to close them again before calling the linker, at which point the linker would re-update the timestamp.

[sethfowler]

Yeah, I can see how the names being unstable make this quite tricky. Regarding the second issue (the linker generating the final artifact), I guess there aren't object files or anything generated directly by the compiler?

[bblum]

This happened to me recently too. It wasn't too annoying for me, but I could see it being a nasty surprise for someone who wasn't paying attention. Nominating for production-ready.

But, even without linking, if rustc keeps the output file open the whole time, won't it still get timestamped at the point when it closes the file descriptor (and hence still be too late)? Another problem about that would be you couldn't run two rustcs at once on different versions of the same source files, which I do occasionally just for the sake of getting quicker error messages (not caring about the actual output).

One probably-pretty-dangerous solution would be to re-timestamp the output files backwards in time to the point at which all the source files were read.

I wonder if we could have rustc record the "source-file-reading time" in the files it generates, and have it later check against that? Seems like you'd need to hack around 'make' though.

[thestinger]

This is still relevant.

[catamorphism]

Just a bug (hopefully will go away with rustpkg)

[emberian]

Still an issue, though I'm not sure how it could be fixed.

[reem]

Visiting for triage. This is still a problem, but it's never happened to me.

[pnkfelix]

I wonder if we could have rustc record the "source-file-reading time" in the files it generates, and have it later check against that? Seems like you'd need to hack around 'make' though.

You can pass explicit timestamps to the touch program, at least the version on my machine. So it seems like we could grab one timestamp at the outset of running make, and use that for all the stamps we generate.

[pnkfelix]

So it seems like we could grab one timestamp at the outset of running make, and use that for all the stamps we generate.

Or better still, grab a separate timestamp at each point that we invoke rustc and subsequently touch an associated stamp file. This is probably the most robust approach.