Generate macros from metadata #3604
Conversation
| g.extend(quote::quote! { | ||
| /// Macro to get the address range of the given memory region. | ||
| #[macro_export] | ||
| macro_rules! memory_range { |
There was a problem hiding this comment.
Why is this a macro? I want to be able to put some of this data into doc comments, and the idea I have is separate macro branches that would generate strings. The main use case is the I2C FIFO size, which we put into a (private) doc comment, and that could look something like property!(i2c_fifo_len, str).
Additionally, these macros are visible globally in esp-hal, so no import statements are needed. I don't intend to create a new macro for each property, but a single property! macro that would have keys, so we don't clutter up the global namespace, but that's not terribly important at this point.
There was a problem hiding this comment.
I like this idea a lot, we often have this information in two places because of the need the value in both code and in docs.
|
I think I'll stop here so that we can evaluate the idea. I hope we'll eventually be able to remove the entirety of the |
|
I guess I like the general idea. At least we should be able to get rid of things like the |
There was a problem hiding this comment.
Overall this approach seems solid to me!
I'd love to be able to import this directly from some other format, but regardless it's probably better to be editing toml files than code when we need new constants. I particularly like the format specifier with the macro branches, I think we'll be able to do some creative things with that.
| g.extend(quote::quote! { | ||
| /// Macro to get the address range of the given memory region. | ||
| #[macro_export] | ||
| macro_rules! memory_range { |
There was a problem hiding this comment.
I like this idea a lot, we often have this information in two places because of the need the value in both code and in docs.
| @@ -182,9 +182,22 @@ | |||
| // MUST be the first module | |||
| mod fmt; | |||
|
|
|||
| #[macro_use] | |||
| /// This module contains code generated by `esp-metadata`. | |||
There was a problem hiding this comment.
Do we even want to publicly document this? Maybe one (and probably should have some mention here anyways) for the DEVELOPER-GUIDELINES?
There was a problem hiding this comment.
This macro shouldn't be publicly visible at all, the documentation is meant to be for us. D-G could use a section about how a driver looks, in general.
The goal of this PR is to rely on esp-metadata more, by generating code from metadata. Eventually this should allow us to better parametrize drivers.