CPP guards for very old Cabal versions in the tests: what do we do?

[Kleidukos]

I found some quite old Cabal versions being taken into account in the tests, especially here:

cabal/Cabal-tests/tests/custom-setup/CabalDoctestSetup.hs

Line 124 in c3f92c4

#if MIN_VERSION_Cabal(1,25,0)

Do we still have an obligation to support Cabal 1.25 in our test suite?

[ffaf1]

Tag Cabal-v1.24.2.0 commit says Thu Dec 8 02:43:11 2016 +0000, so 6½ years ago. I can imagine relatively old Haskell being deployed somewhere, I can’t imagine a situation where they would want to build cabal head.

[andreabedini]

I am planning to drop support for anything earlier than what is promised (of the top of my head: 5-year old GHCs for Cabal and 3-year old GHCs for a cabal-install)

There's lot of ifdefs, special behaviours and work arounds for GHC<8!

I have a WIP in a branch, but I need to double check as I might have got my GHC versions wrong and removed support for one version later 😅 I guess we can wait until September to merge 🤣

Edit:

https://github.com/andreabedini/cabal/tree/andrea/wip/drop-ghc-before-8-6-1

[Mikolaj]

Yes, that's a great idea. Let's clean up the cruft. But let's remember new cabal needs to work with even older GHCs, that are not supposed to be able to compile cabal. So if any of the ifdefs relate to cabal API or cabal-GHC protocol changes, that requires an extra discussion.

[andreabedini]

But let's remember new cabal needs to work with even older GHCs, that are not supposed to be able to compile cabal.

Oh, thank you @Mikolaj for making this distinction! I have the impression it is not properly captured in CONTRIBUTING.md, which says, generically, support and seems to identify it with buildable out-of-the-box.

Our GHC support window is five years for the Cabal library and three years for cabal-install: that is, the Cabal library must be buildable out-of-the-box with the dependencies that shipped with GHC for at least five years.

As you allude to, what "support" entitles can be tricky. E.g. GHC 8.0.2 (2017-01-11) shipped with Cabal-1.24.2.0; but one can obtain cabal-install-3.10.1.0 (e.g. compiled with GHC 9.6.2) which can use its internal Cabal-3.10.1.0 to "drive" GHC 8.0.2. In another scenario (e.g. a custom setup) cabal-install-3.10.1.0 will have to talk to Cabal-1.24.2.0 (I think?).

As far as I can see , "support" can have at least these meanings:

• Cabal can be built with GHC X.Y.Z boot packages
• cabal-install can be built with GHC X.Y.Z
• Cabal can drive with GHC X.Y.Z
• cabal-install can drive Cabal A.B.C.D

I think we need to clarify this topic so we can be all on the same page.

[fgaz]

Cabal can drive with GHC X.Y.Z

Currently we support ghc >= 7.0.1 && < 9.8:

cabal/Cabal/src/Distribution/Simple/GHC.hs

Lines 164 to 182 in a191f0a

	(ghcProg, ghcVersion, progdb1) <-
	requireProgramVersion
	verbosity
	ghcProgram
	(orLaterVersion (mkVersion [7, 0, 1]))
	(userMaybeSpecifyPath "ghc" hcPath conf0)
	let implInfo = ghcVersionImplInfo ghcVersion
	-- Cabal currently supports ghc >= 7.0.1 && < 9.8
	-- ... and the following odd development version
	unless (ghcVersion < mkVersion [9, 8]) $
	warn verbosity $
	"Unknown/unsupported 'ghc' version detected "
	++ "(Cabal "
	++ prettyShow cabalVersion
	++ " supports 'ghc' version < 9.8): "
	++ programPath ghcProg
	++ " is version "
	++ prettyShow ghcVersion

cabal-install can drive Cabal A.B.C.D

Currently Cabal >= 1.20

cabal/cabal-install/src/Distribution/Client/ProjectPlanning.hs

Lines 1390 to 1438 in a191f0a

	-- While we can talk to older Cabal versions (we need to be able to
	-- do so for custom Setup scripts that require older Cabal lib
	-- versions), we have problems talking to some older versions that
	-- don't support certain features.
	--
	-- For example, Cabal-1.16 and older do not know about build targets.
	-- Even worse, 1.18 and older only supported the --constraint flag
	-- with source package ids, not --dependency with installed package
	-- ids. That is bad because we cannot reliably select the right
	-- dependencies in the presence of multiple instances (i.e. the
	-- store). See issue #3932. So we require Cabal 1.20 as a minimum.
	--
	-- Moreover, lib:Cabal generally only supports the interface of
	-- current and past compilers; in fact recent lib:Cabal versions
	-- will warn when they encounter a too new or unknown GHC compiler
	-- version (c.f. #415). To avoid running into unsupported
	-- configurations we encode the compatibility matrix as lower
	-- bounds on lib:Cabal here (effectively corresponding to the
	-- respective major Cabal version bundled with the respective GHC
	-- release).
	--
	-- GHC 9.2 needs Cabal >= 3.6
	-- GHC 9.0 needs Cabal >= 3.4
	-- GHC 8.10 needs Cabal >= 3.2
	-- GHC 8.8 needs Cabal >= 3.0
	-- GHC 8.6 needs Cabal >= 2.4
	-- GHC 8.4 needs Cabal >= 2.2
	-- GHC 8.2 needs Cabal >= 2.0
	-- GHC 8.0 needs Cabal >= 1.24
	-- GHC 7.10 needs Cabal >= 1.22
	--
	-- (NB: we don't need to consider older GHCs as Cabal >= 1.20 is
	-- the absolute lower bound)
	--
	-- TODO: long-term, this compatibility matrix should be
	-- stored as a field inside 'Distribution.Compiler.Compiler'
	setupMinCabalVersionConstraint
	| isGHC, compVer >= mkVersion [9, 6] = mkVersion [3, 10]
	| isGHC, compVer >= mkVersion [9, 4] = mkVersion [3, 8]
	| isGHC, compVer >= mkVersion [9, 2] = mkVersion [3, 6]
	| isGHC, compVer >= mkVersion [9, 0] = mkVersion [3, 4]
	| isGHC, compVer >= mkVersion [8, 10] = mkVersion [3, 2]
	| isGHC, compVer >= mkVersion [8, 8] = mkVersion [3, 0]
	| isGHC, compVer >= mkVersion [8, 6] = mkVersion [2, 4]
	| isGHC, compVer >= mkVersion [8, 4] = mkVersion [2, 2]
	| isGHC, compVer >= mkVersion [8, 2] = mkVersion [2, 0]
	| isGHC, compVer >= mkVersion [8, 0] = mkVersion [1, 24]
	| isGHC, compVer >= mkVersion [7, 10] = mkVersion [1, 22]
	| otherwise = mkVersion [1, 20]

[philderbeast]

Currently we support ghc >= 7.0.1 && < 9.8:

The announcement for ghc-7.0.1 was made 2010-11-15, that is:

12 years, 7 months, 3 days ago
SOURCE: Days Calculator: Days Between Two Dates

[ulysses4ever]

@philderbeast

The announcement for ghc-7.0.1 was made 2010-11-15, that is: 12 years, 7 months, 3 days ago

Do you mean we should drop it on grounds of being too old? But we're not doing anything special, as this is the version of GHC we can "drive" rather than compile with (see discussion above). So, I don't think we have to do anything about that. Maybe apart from checking that this is still the case for newer Cabals. I think this is what "Validate old ghcs" job does?..

---

@ All,

should we put compatibility data discussed in this thread in a visible place? E.g. README.md or CONTRIBUTING.md or anything else?

[Kleidukos]

Yes I would rather appreciate if there was a clear and unique source of information regarding this.

[philderbeast]

Getting rid of some very old CPP #if conditionals could help us when we follow up on #9041, likely with these two:

# Warnings currently triggered by your code
- ignore: {name: "Unused LANGUAGE pragma"} # 121 hints
- ignore: {name: "Use fewer imports"} # 13 hints

[ulysses4ever]

@philderbeast that would be very good, thank you for clarifying! But support for driving GHC 7.0 shouldn't cost us any CPP as far as I understand.

[philderbeast]

Thanks @ulysses4ever and others for mentioning GHC versions that cabal can drive. Seems like we support a hell of a lot of GHC versions for building and testing of cabal the project itself. As a user of cabal, I'll get it via ghcup. For developing and maintaining cabal, do we need to support building with versions older than ghc-9.4.8?

cabal/.github/workflows/validate.yml

Line 52 in ce5d0f7

ghc: ["9.8.1", "9.6.3", "9.4.8", "9.2.8", "9.0.2", "8.10.7", "8.8.4", "8.6.5", "8.4.4"]