In the lane_table branch I'm using an executable to debug the algorithm and print a graphviz graph for the state machines.
Outside of debugging, a CLI can be used to build parsers in a build script. This can help avoiding redundant recompilations until we make the proc macro cache its outputs.
Here's the crate structure I have in mind:
parsegen_lib will be the main thing. This is basically the current parsegen crate, except it shouldn't be marked as a proc macro.
parsegen_cli should provide a parsegen executable that can compile parsegen inputs to Rust using parsegen_lib. It should have flags for debug outputs, generating graphviz etc.
parsegen: A proc_macro wrapper around parsegen_lib.
To allow debugging proc macro usage, parsegen_cli should have a simple parser to extract the parser! { ... } part of a file and pass it to parsegen_lib. This way we don't have to add syntax to the proc macro for debugging, we can pass debug flags to parsegen_cli, and pass it the file with parsegen parser(s).
In the lane_table branch I'm using an executable to debug the algorithm and print a graphviz graph for the state machines.
Outside of debugging, a CLI can be used to build parsers in a build script. This can help avoiding redundant recompilations until we make the proc macro cache its outputs.
Here's the crate structure I have in mind:
parsegen_libwill be the main thing. This is basically the currentparsegencrate, except it shouldn't be marked as a proc macro.parsegen_clishould provide aparsegenexecutable that can compile parsegen inputs to Rust using parsegen_lib. It should have flags for debug outputs, generating graphviz etc.parsegen: A proc_macro wrapper aroundparsegen_lib.To allow debugging proc macro usage,
parsegen_clishould have a simple parser to extract theparser! { ... }part of a file and pass it toparsegen_lib. This way we don't have to add syntax to the proc macro for debugging, we can pass debug flags toparsegen_cli, and pass it the file withparsegenparser(s).