Nor is it the case that changing a .rs file in the compiler causes an LLVM rebuild. Again, this has *never* been the case.
-
-
So if LLVM is being rebuilt when the docs change, it is a problem specific to the CI, and it should be solved *there*. Because if you change the build system to Bazel, and don’t fix *that* issue, it will *still* be a problem.
1 reply 0 retweets 2 likes -
This Tweet is unavailable.
-
Now we’re getting somewhere. The reason why that triggered a rebuild is that the compiler couldn’t tell—or, more likely, incremental compilation lacked the hooks to tell the build system—that a rebuild was not necessary.
1 reply 0 retweets 0 likes -
This is a problem that needs to be solved! But it needs to be solved *in the compiler*. The problem is presumably that the compiler, right now, can’t say “oh, I didn’t need to rebuild anything” in a way that the build system can understand.
3 replies 0 retweets 1 like -
Replying to @BRIAN_____ @sayrer and
How is the build system supposed to know? Does Bazel have a magic Rust parser that can understand comment changes?
2 replies 0 retweets 0 likes -
Replying to @pcwalton @BRIAN_____ and
Bazel's dependency graph goes down to the file level. If your test doesn't have transitive edges going to a doc, the test will not rerun if the doc changes. That said, if your compiler changes, expect all tests to rerun.
1 reply 0 retweets 0 likes -
Replying to @jin_ @BRIAN_____ and
This is my point. File-level dependency tracking is something we already do in Cargo. (Actually, Cargo uses incremental compilation, so it’s *better* than file-level.) It wouldn’t have helped this case, precisely because it’s file-level.
1 reply 0 retweets 1 like -
Replying to @pcwalton @BRIAN_____ and
If the Bazel Rust rules produce an "ABI" kind of output, you don't need to re-run downstream actions. This is what the Java/JVM rules do with interface jars.
2 replies 0 retweets 0 likes
Yes, my point is that we have to do compiler work first to integrate with the build system. (BTW, Cargo already integrates with incremental compilation in this way.)
-
-
This Tweet is unavailable.
-
We already do that in rustc, for that exact reason (Cargo does what you describe). Look at how many subcrates are under src/. Splitting up into fine grained crates to help with build time is a process that has been going on for years.
1 reply 0 retweets 0 likes - 4 more replies
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.