Set `CABAL_VERSION` environment variable when calling out to executables

[hvr]

I couldn't figure out if there is already something like this in place, but I think it may be useful to have this kind of information available to programs called by the Cabal library. Or rather, I see no downside to provide this information, even if programs don't need it yet. OTOH, changes like https://phabricator.haskell.org/D1780 do occur from time to time. And Cabal has no way to know about future GHC versions, however, GHC can know about past (incompatible) Cabal versions.

With such an environment variable ghc-pkg or ghc could optionally inspect the CABAL_VERSION environment variable, and warn (or adapt their behaviour) if the Cabal library version is known to be unaware of recent changes in GHC's behaviour.

/cc @ezyang

UPDATE: #415 is somewhat related

[ezyang]

I'm fine with this.

[hvr]

We may want to pass something like this as CPP macro as well... i.e. -DCABAL_VERSION=12401 for 1.24.01 (assuming we never need more than 2 digits per component)

[23Skidoo]

@hvr

We may want to pass something like this as CPP macro as well... i.e. -DCABAL_VERSION=12401 for 1.24.01 (assuming we never need more than 2 digits per component)

Why isn't the MIN_VERSION_ macro sufficient?

[ezyang]

MIN_VERSION_ indicates what version of Cabal a library is linked against. The putative CABAL_VERSION macro would indicate what version of Cabal is BUILDING the package. A new version of Cabal could link a package with an old version of Cabal, in which case these values are different; most packages aren't built to be linked against Cabal, etc.

[hvr]

@23Skidoo what ezyang said, and maybe https://phabricator.haskell.org/D1869 provides a bit more context; it maybe useful for code to know when it's being built via Cabal, as then e.g. things like a Paths_* module may exist.

[ezyang]

@hvr do you want this milestoned for 2.0? Would you like to write the patch :)