The current API for Generator and Addon is not flexible enough to generate multiple files; in particular the problem is mostly with the Addon. As a refresher, at the time of writing the two traits look like this (removing useless info):
trait Generator {
fn generate(
&self,
registry: &DefinitionRegistry,
initial_filename: &str,
) -> Result<Vec<GeneratedSource>, GenerationError>;
// <snip>
}
trait Addon {
fn preamble(&self, registry: &DefinitionRegistry) -> Option<Cow<'static, str>>;
fn content(&self, registry: &DefinitionRegistry) -> Option<Cow<'static, str>>;
fn postamble(&self, registry: &DefinitionRegistry) -> Option<Cow<'static, str>>;
}
The Generator can output multiple files (Vec<GeneratedSource>), but the Addon only works on parts of an individual file.
Why would we care about this?
For C++, it would have the nice benefit of allowing us to generate forward declarations, so that could possibly make compilation faster. In general, it would allow someone to extend the CLI for languages which care about the source files and their definitions (e.g., Java or C#).
This issue is partially related to #13 and #22.
Bikeshedding
One way I was thinking about this is that a Generator should pass an Addon some context about what it's generating and where. So the Addon becomes part of a state machine. For example, if keeping the preamble-content-postamble structure:
pub struct SourceGenerationContext<'a> {
/// The definition we are currently generating code for.
definition: DefinitionRef,
/// The file name the [`Generator`] choose to attach to this definition.
tentative_filename: Option<&'a str>,
}
trait Addon {
fn preamble(&self, ctx: SourceGenerationContext, registry: &DefinitionRegistry) -> Option<Cow<'static, str>>;
fn content(&self, ctx: SourceGenerationContext, registry: &DefinitionRegistry) -> Option<Cow<'static, str>>;
fn postamble(&self, ctx: SourceGenerationContext, registry: &DefinitionRegistry) -> Option<Cow<'static, str>>;
}
I don't know if the above suffices for Java or C#, but it may work for multi-file C++ (?).
I should add, though, that the above does not work if we want to generate library-specific tests; in that case the Addon should be able to tell the Generator to add more files (the test files), turning the whole API into a state machine of sorts.
The current API for
GeneratorandAddonis not flexible enough to generate multiple files; in particular the problem is mostly with theAddon. As a refresher, at the time of writing the two traits look like this (removing useless info):The
Generatorcan output multiple files (Vec<GeneratedSource>), but theAddononly works on parts of an individual file.Why would we care about this?
For C++, it would have the nice benefit of allowing us to generate forward declarations, so that could possibly make compilation faster. In general, it would allow someone to extend the CLI for languages which care about the source files and their definitions (e.g., Java or C#).
This issue is partially related to #13 and #22.
Bikeshedding
One way I was thinking about this is that a
Generatorshould pass anAddonsome context about what it's generating and where. So theAddonbecomes part of a state machine. For example, if keeping the preamble-content-postamble structure:I don't know if the above suffices for Java or C#, but it may work for multi-file C++ (?).
I should add, though, that the above does not work if we want to generate library-specific tests; in that case the
Addonshould be able to tell theGeneratorto add more files (the test files), turning the whole API into a state machine of sorts.