Add preCompile config key to gftools-builder

[felipesanches]

Important

This issue was written by an AI agent (Claude Code) working under the guidance of @felipesanches.

Summary

Many upstream Google Fonts repos need to run preparation scripts before invoking gftools-builder. Currently 61 repos use custom Python build scripts and 19 use custom shell scripts as wrappers around the build process. Adding a preCompile configuration key would let these projects move to a pure config.yaml-driven build.

Proposed Design

A new preCompile key in config.yaml that takes a list of shell commands to run before the build process begins:

sources:
  - MyFont.glyphs
preCompile:
  - python3 scripts/fix_sources.py
  - bash scripts/generate_data.sh

How it differs from postCompile

• preCompile: Shell commands that run as subprocesses before the build graph is created. They can modify source files, generate data, etc. They run after chdir to the config directory but before the recipe provider reads sources.
• postCompile: Build operations that run on compiled font binaries within the ninja build graph.

This distinction is intentional — preCompile commands operate on source files (before fontmake runs), so they don't fit naturally into the ninja dependency graph as operations with $in/$out.

Implementation sketch

1. Schema: Add Optional("preCompile"): Seq(Str()) to GOOGLEFONTS_SCHEMA
2. Builder __init__: Run each command via subprocess.run(cmd, shell=True, check=True) after config parsing + chdir, but before calling the recipe provider
3. Docs: Add documentation alongside the existing postCompile entry

Questions for @simoncozens

1. Does running preCompile commands as subprocesses (outside the ninja graph) seem like the right approach, or would you prefer them integrated into the build graph somehow?
2. Is Seq(Str()) (list of shell command strings) the right schema, or should it support operation dicts like postCompile does?
3. Any concerns about shell=True for running these commands? (It's needed for things like pipes and shell builtins, and matches what users would type in a terminal.)

[felipesanches]

@simoncozens, I reviewed the Claude-aided summary above and agree with its contents. Please let me know how you feel about this feature proposal. It will be useful for 2 main goals: (a) Make the build instructions for repos consumed by fontc_crater more precise, thus reducing the number of build errors in their dashboard. (b) it is an important step towards explicitly, precisely and uniformly documenting build rules for the entire Google Fonts library.

[felipesanches]

If you agree, I'll prepare a PR with an implementation.

[simoncozens]

The point of gftools-builder is to have a standardised or near-standardised build script, made up of well-known components. I agree that allowing arbitrary shell commands to run beforehand may be useful in terms of just getting things building, but it's a step in the wrong direction.

In my mind, having a pre-compile sequence which runs python3 scripts/fix_sources.py within gftools-builder does not actually buy you anything over running python3 scripts/fix_sources.py; gftools-builder. It certainly won't be allowed as we move to Rust.

[felipesanches]

My reasoning was to treat config.yaml as the stardardized entry point for font building, with scope analogous to that of a Makefile.

[simoncozens]

I understand, but Rod is very unhappy with arbitrary code execution except for pathological cases (Playwrite etc.). It's something we need to move away from, not grandfather in.