cmd/gg: revisit fixed-point approach

[myitcv]

The current fixed-point logic in cmd/gg is based on the following original "requirement": that the outputs of one generator can act as inputs to another generator in the same package. It does come at a cost, however:

1. each directive in a given package is run at least twice
2. gg has a more complex implementation

The first cost is almost complete mitigated by the gg cache (except where you are making changes the development cycle can be slowed in some situations). The second cost remains.

Firstly, it's worth considering whether this is even a valid "requirement". The problem can, to a certain extent, be side-stepped by adapting one of the mutually dependent generators to know about the other, in effect reducing two directives (n in the general case) down to one. This would in effect leave you in a situation where for a given package, no two directives are mutually dependent.

However this doesn't guarantee that you will never encounter a situation of mutual dependence. The fixed-point logic acts as a good back stop in this respect.

As @rogpeppe observed, an argument against this (overly-)defensive approach is that some generators may be non-deterministic (unintentionally of course). This point is largely mitigated by having a CI run:

• remove all generated files
• re-run gg
• check there is zero git diff (or equivalent)

If the fixed-point logic were removed, you could still end up with zero git diff. But this would offer no guarantee you wouldn't generate a diff the second time around, i.e. by re-running gg.

Plenty of food for thought.