Consider build generation (e.g. ninja)

[calebzulawski]

This doesn't solve one particular problem, but has a variety of benefits (and a few drawbacks)

Benefits

• using a "mainstream" build tool
  • less maintenance/development
  • get all of the features of ninja (target dumping, graph visualization, output purging, compile commands) for "free"
  • integrate better with some inflexible tooling (e.g. Coverity) more easily
• two stage build (configure-build)
  • faster edit-compile-run loops: ninja is optimized for a particular type of graph and is much faster than ergo
  • an explicit two stage build can be simpler than ad hoc/lazy, e.g. external dependency tracking/vendoring done in the configure step
• works around various current bugs or ergo limitations
  • Too many open files error during dependency detection #6 probably no longer an issue
  • cache-policy = configuration is often insufficient and maybe buggy #4: caching could be much simpler and likely depend only on configuration
  • might work around evaluation caching memory leak

Drawbacks/Unanswered Questions

• build recipe regeneration
  • should all targets be configured/enumerated up front? should modules be split across ninja files to minimize changes?
• files are only tracked by timestamp
  • doesn't play nice with git branching, or reverting changes
  • solved by using ccache or sccache (sccache does much more than ergo's simple local build caching)
• how to deal with "custom" modules? (e.g. external dependencies, code generation)
  • modules could contain a configure step (ergo code executed the first time the target is requested) and a command step (written in, or generates, ninja build rules)

[afranchuk]

I understand the motivation here for sure, but I think if you go this route then ergo is not the right choice of tool. The language was purpose-built to fill the ninja/make niche, with features tailored to that behavior. Of course there are still kinks to work out and optimizations to be made, so it can have unintended latencies. Scripts which are simple to reason about tend to be very fast, correct, and do minimal work (like ninja/make). The higher-level abstractions are where behaviors need to be improved.

This is why I think targeting another tool isn't really appropriate for ergo, because you'd be replacing the thing it strives to do best with something else, and would retain the things that aren't quite optimal (using it as a general purpose scripting language).