Add PackageMeta_ autogenerated module (#11755)

[angerman]

Summary

Adds a new autogenerated module PackageMeta_<pkgname> that exposes build-environment metadata known at configure time. This complements the existing PackageInfo_<pkgname> (static .cabal metadata) and Paths_<pkgname> (install paths).

Closes #11755.
Related: #392, #826, #1506, #7355, #7488, #11258, #4746.

What PackageMeta_ provides

module PackageMeta_mypackage where

compiler        :: String   -- e.g. "ghc"
compilerVersion :: Version  -- e.g. Version [9,6,7] []
os              :: String   -- e.g. "linux", "darwin"
arch            :: String   -- e.g. "x86_64", "aarch64"
gitRevision     :: String   -- e.g. "abc123..." or ""
gitDirty        :: Bool     -- working tree dirty?
flag_debug      :: Bool     -- one Bool per cabal flag
flag_benchmarks :: Bool

Taxonomy

Module	Changes when...	Content
PackageInfo_	.cabal file edited	name, version, synopsis, copyright, homepage
PackageMeta_ (new)	Build environment changes	compiler, os, arch, flags, gitRevision
Paths_	Package installed to different prefix	bindir, libdir, datadir

Implementation

Follows the exact pattern established by PackageInfo_ (PR #8534):

• Distribution.Simple.Build.PackageMetaModule -- generation logic
• Distribution.Simple.Build.PackageMetaModule.Z -- Zinza-style renderer
• autogenPackageMetaModuleName added to BuildPaths
• Wired into builtinAutogenFiles in Build.hs
• Filtered from sdist in SrcDist.hs
• Test cases following the PackageMetaModule/ pattern

Note on git revision: generatePackageMetaModule accepts the git revision and dirty flag as parameters (since computing them requires IO, and builtinAutogenFiles is pure). This PR passes empty defaults ("", False). Wiring up the actual git rev-parse HEAD call at the appropriate IO call site is left for a follow-up, pending discussion on the issue about whether VCS info should be opt-in.

Test plan

• Verify PackageMetaModule.hs and Z.hs compile
• Verify generated module is valid Haskell (validated end-to-end with standalone renderer test)
• Verify cabal check warnings for missing autogen-modules
• Verify sdist filtering works
• Run existing test suite to check for regressions

[zlonast]

Why do we need to leave a todo here? It seems like everything can be solved right here.

builtinAutogenFiles is only used in writeBuiltinAutogenFiles :: ... -> IO ()

[tdammers]

Not really convinced of the git parts, for several reasons:

• Getting the required information into cabal is going to be messy no matter how you spin it
• Invoking git from within cabal adds attack surface (especially if it's not opt-in)
• Recompilation checks will get complicated: you will need to re-run a git command for every build to check whether the PackageMeta module needs to be rebuilt
• Git isn't the only VCS out there - it's ubiquitous to the point that a lot of people will think you're insane if you use anything else, but I still think hard-coding "everyone uses git anyway" as an assumption into a build system is not a great idea
• Injecting git revision information into an executable is already possible without this (shelling out to git from Template Haskell), and doing it separately gives you much more flexibility - e.g., you can pick up branch names, tag names, etc., and interpret them according to the project's conventions, rather than just getting a commit hash and a "dirty" flag.
• The git fields don't actually do anything yet; until the code that fills them is in place, they're just dead weight, so I'd suggest merging this without the git fields, and implement those, together with code to fill them, separately.

[Mikolaj]

@angerman: could I help move this forward?

[angerman]

@angerman: could I help move this forward?

@Mikolaj by all means yes! I'm currently swamped with other stuff 😖

@tdammers TH is imo not a solution for this (th-embed and all these others), TH shelling out to tools during compile time is IMO utterly insane. I absolutely agree that there are other VCS, git just happens to be the dominant one today, I have no objection to making this more vcs agnostic though; git was just what I needed right now.