6 ms·

Why is the generated code checked in, vs generated as-needed later?

• onei 5y ago
  Pure speculation on my part, but I've noticed Go has generate and build as separate steps and it's standard to check in generated code. This split no doubt makes compilation a lot simpler/faster, but perhaps it's a reflection of standard practices the language authors were used to.
• azurezyq 5y ago
  Most of them are generated on the fly, like protos. But you know, there are tons of configs, all kinds of.
• danpalmer 5y ago
  Traceability, simplicity, all sorts of reasons. If you commit all your codegen’d stuff you don’t need to worry about how to run codegen in most places. You can enforce a lot of security properties, you can run large scale analysis on the code in production because it’s all “statically” available, etc. That said, I think Google’s source control ecosystem is really quite different to what’s publicly available with systems like Git/Hub/Lab etc, even to Phabricator. These approaches work well at Google but don’t necessarily translate to other tools in the same way. Don’t take these sorts of things as gospel, or even as google advice about good engineering. Understand what they achieve, and then figure out a way to achieve that same result with the tools available to you.
• exikyut 5y ago
  Theory: it makes secure builds that much more straightforward. You can just point goma at a repo and whatever it inhales is everything needed. The simplicity cascades downwards. For example, "everything comes from a repo" would make object (.o) caching that much more straightforward. And you can reason both about the logic behind a service and how it was configured from a single commit hash/CL.