Automatically add dependency on manifest file.#190
Automatically add dependency on manifest file.#190de-vri-es wants to merge 1 commit intodiondokter:masterfrom
Conversation
| if let Some(path) = file_path.to_str() { | ||
| output += | ||
| "e::quote! { const _: &[u8] = ::core::include_bytes!(#path); }.to_string(); | ||
| } else { | ||
| diagnostics.add_warning("Manifest path contains invalid Unicode, automatic dependency tracking will not work. Consider renaming the manifest file."); | ||
| } |
There was a problem hiding this comment.
Note that I don't think you can actually provide a path with invalid Unicode, as the path has to be passed as a macro argument from a Rust source file.
So it might be fine to just unwrap() and remove the warning.
|
Hmmm, you've expressed this desire before: #146 I'll consider it again... |
|
If you want the adding of the dependency tracking can be moved from the compiler to the macro. Only downside is that then the macro crate should also depend on And then the compiler lib doesn't have to know anything about dependency tracking. |
de-vri-es
force-pushed
the
track-manifest-as-dependency
branch
from
5052a0c to
d377b37
Compare
Moved it to the macro crate. Much smaller diff in total and arguably a cleaner place to implement this. But now the macro crate depends on |
|
Ok, I've decided. I don't want this. For no other reason really than 'it feels wrong to me'. Sorry :) |
|
Eh? This is the standard way that proc-macros do this kind of thing. It's much more fool-proof than a build script, and it saves compiling the build script too. I'm struggling to see a downside 😮 |
|
The largest driver written with device-driver I know about is in a private repo and clocks in at 354 KB. That's large, but not as large as imaginable. For example, the STM32H753 SVD file is 3.84 MB. The thing that feels bad about it is that we'd be asking the compiler to include a string of potentially multiple megabytes only to then ignore it. That driver of 354 KB I mentioned already starts lagging Rust Analyzer and I don't want to add to that. There is a real solution: rust-lang/rust#99515 Also, I use macro expansion a lot to view the source of a driver and I don't want to see the original source code there again. That's not great debugging. So, it is just how it is until Rust provides a better way. (I am thinking about adding an additional way to build the drivers. Namely something you can add as a build-dependency instead of a macro) |
Well, it's up to you of course, but I don't think And the input file will just have been read by the proc-macro, so on the bright side it's probably in the OS disk cache already ^_^
I do understand the pain of debugging proc macros. Even But since this project already has the rust-lang/rust#99515 doesn't seem likely to produce anything usable any time soon, as it doesn't seem the discussion around the public API is progressing much. In the mean time there's a pretty workable solution, I think. But again, up to you ^_^ |
|
Oh, and if you let rust-analyze inline the macro for you, you won't see the file contents. You will see the |
2 participants
This PR adds a
const _: &[u8] = include_bytes($manifest_path)to automatically trigger recompilation if the manifest changes. This way, no build script is needed for that anymore.Tested with a simple example and
cargo expand, showing this line ending up at the top of the the expanded source:The dependency tracking is only added when the input is a manifest and not when using the CLI.