Why .gitignore meta/src/grammar.rs? #558
-
As I understand it so far (still learning the codebase), grammar.rs is generated by the |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
The general reason is that generally, you shouldn't put generated files in source control. But more generally, the bootstrap system is quite messy. Previously, pest@2 used pest@1 for its grammar, IIRC. I'm the one who set up the current bootstrap to avoid the cyclic requirement. The ultimate goal is that crates-io users don't have to build more than one pest, but we can still dogfood by using crates-io pest to develop the next release of pest. I've played on-and-(mostly)-off with a way of "properly" solving the bootstrap problem (specifically for the case of using watt to drive proc macro crates). The ideal is that
For a binary blob like wasm, that changes any time anything in the macro impl is changed, not committing it to the repo is more important. r-a is a notable example of tracking generated source files in source control, and their use case likely changes around the same amount as the pest grammar would change. I'm not strongly against committing the generated source file again, so long as it's marked as generated and a test to make sure it's up-to-date. |
Beta Was this translation helpful? Give feedback.
The general reason is that generally, you shouldn't put generated files in source control.
But more generally, the bootstrap system is quite messy. Previously, pest@2 used pest@1 for its grammar, IIRC. I'm the one who set up the current bootstrap to avoid the cyclic requirement. The ultimate goal is that crates-io users don't have to build more than one pest, but we can still dogfood by using crates-io pest to develop the next release of pest.
I've played on-and-(mostly)-off with a way of "properly" solving the bootstrap problem (specifically for the case of using watt to drive proc macro crates). The ideal is that
cargo build
just works, but more importantly, that the two library-user us…