Prevent duplication of include_bytes! statements
#85
Conversation
| @@ -88,6 +89,23 @@ impl<'a> Generator<'a> { | |||
| Ok(buf.buf) | |||
| } | |||
|
|
|||
| fn generate_include_bytes<S: AsRef<str>>(&mut self, buf: &mut Buffer, path: S) { | |||
| static CACHE: OnceLock<OnceMap<String, &'static ()>> = OnceLock::new(); | |||
There was a problem hiding this comment.
Thinking about it, I don't think using a cache this why is sane:
- Given the file
layout.htmlis used in compiling unitsa.rsandb.rs, then the include might wind up only in one of the generated objects, say,a.rs. - Afterwards, we remove
a.rsand any mentions to it. - Then we alter
layout.html:b.rsdoes not mention the dependency, so the change won't cause a recompilation.
There was a problem hiding this comment.
If we remove a.rs, the crate will be recompiled and layout.html will be used in b.rs. Or did I miss something?
There was a problem hiding this comment.
You cannot assume that the whole crate is recompiled when incremental compilation is enabled, can you?
There was a problem hiding this comment.
Hum... It's a good question. But since you remove a.rs, it also means you remove mod a somewhere else, so in this case, I wonder if the whole crate isn't simply rebuilt...
There was a problem hiding this comment.
But what if the add more indirection? (Assume the usual folder structure):
mod x1 {
mod x2 {
mod a;
}
mod x3 {
mob b;
}
}Then removing mod a will cause a recompilation of mod x2, but not x1. If the need to rebuild would bubble up, then there could be no incremental compilation.
There was a problem hiding this comment.
The fact that we're debating over this is already a pretty good sign that we should not do it. Closing then! :)
There was a problem hiding this comment.
Maybe once upon a time rust-lang/rust#99515 gets implemented. :) If I understand the proposal correctly, then this could be a game changer, and we could even use spans inside the template file to show error messages, etc.
Fixes #72.