A release tarball carries generated files that a git tree does not, and
two of those bit us.
`MD5SUMS` is generated when a tarball is rolled. Each sub-source
extractor asserted `[[ -f MD5SUMS ]]` before copying it, so every one of
them failed outright the moment `monorepoSrc` was a git tree:
unpacking source archive /nix/store/...-source
source root is source
<exit 1>
Copy it only when it is there.
The generated sources are the other half: a checkout lacks
`gengtype-lex.cc` and friends, which a tarball ships pre-built, so they
have to be regenerated. Take flex and bison as native inputs when
`fromVCS` says the source is a checkout.
Tarball builds are unaffected either way.
Assisted-by: Claude Code (Claude Opus 5)
Because we're building things separately, we don't need the fancy
lib/... namespacing tricks that GCC normally does to squeeze itself in
the FHS. We can just use the normal autotools libdir and include dir,
and the nixpkgs infra will sort everything out.
Where possible I submitted patches to the mailing list, and fetched
those. The ones I am vendoring are the residuals which I don't think are
ready for upstreaming yet. (I can imagine a further reworking upstream
such that we wouldn't need our own patches of that sort, but it would be
good to get the first crop merged first before discussing that.)
