PackageInfo functionality is not guarded behind `cabal-version`.

[phadej]

Given a package with just foo.cabal:

cabal-version: 2.4
name: foo
version: 0
license: BSD-3-Clause
license-file: LICENSE
maintainer: Someone
category: Example
synopsis: Foo
description: FooBar
build-type: Simple

library
  default-language: Haskell2010
  build-depends: base <5
  autogen-modules: PackageInfo_foo
  exposed-modules: PackageInfo_foo

cabal-install-3.10.1.0 check doesn't complaint, and cabal build succeeds:

% ~/.ghcup/bin/cabal-3.10.1.0 check
No errors or warnings could be found in the package.

% ~/.ghcup/bin/cabal-3.10.1.0 build
Resolving dependencies...
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - foo-0 (lib) (configuration changed)
Configuring library for foo-0..
Preprocessing library for foo-0..
Building library for foo-0..
[1 of 1] Compiling PackageInfo_foo  ( ... )

---

However older cabal-installs, or if I change to build-type: Custom (and use say GHC-9.2.7) fails.

Older cabal-install (note, you need to clear dist-newstyle in between so autogenerated left-overs are removed):

% ~/.ghcup/bin/cabal-3.6.2.0 check 
No errors or warnings could be found in the package.

[polinukli] /codetmp/foo % ~/.ghcup/bin/cabal-3.6.2.0 build
Build profile: -w ghc-8.6.5 -O1
In order, the following will be built (use -v for more details):
 - foo-0 (lib) (first run)
Preprocessing library for foo-0..
cabal-3.6.2.0: can't find source for PackageInfo_foo in .,
/codetmp/foo/dist-newstyle/build/x86_64-linux/ghc-8.6.5/foo-0/build/autogen,
/codetmp/foo/dist-newstyle/build/x86_64-linux/ghc-8.6.5/foo-0/build/global-autogen

or with build-type: Custom:

% grep -A 4 build-type foo.cabal                
build-type: Custom

custom-setup
  setup-depends: base, Cabal

[polinukli] /codetmp/foo % ~/.ghcup/bin/cabal-3.10.1.0 build -w ghc-9.2.7
Build profile: -w ghc-9.2.7 -O1
In order, the following will be built (use -v for more details):
 - foo-0 (lib:foo) (cannot read state cache)
Configuring foo-0...
Preprocessing library for foo-0..
setup: can't find source for PackageInfo_foo in .,
/codetmp/foo/dist-newstyle/build/x86_64-linux/ghc-9.2.7/foo-0/build/autogen,
/codetmp/foo/dist-newstyle/build/x86_64-linux/ghc-9.2.7/foo-0/build/global-autogen

Error: cabal-3.10.1.0: Failed to build foo-0.

---

Features changing cabal_macros.h, Paths_pkgname.hs etc SHOULD be guarded behind cabal-version.

[andreabedini]

What can we do to prevent this kind of mistakes? The only things I can think of are:

1. some automation to add warnings and extra checks when a PR changes particular files
2. use something like structureHash to make sure changes in some datatypes are visible and acknowledged.

[phadej]

For each feature request / pull request you (= maintainers) should always answer the question "is this a change which should be guarded by cabal-version: ..."

(c.f. GHC folks ask themselves "does this need a GHC proposal").

Either it's clearly doesn't need to, or if someone is unsure, they should discuss. This kind of mistakes are very bad. IMO they also should be the highest priority to fix (or revert) - at least before Hackage starts using the affected Cabal versions. And it already does https://github.com/haskell/hackage-server/blob/30a4d8404dd9b70be0f00545d14a640b291107fc/hackage-server.cabal#L150, so "broken" packages can be uploaded to Hackage, which is permanent store.

[andreabedini]

I understand that these mistakes are bad; and that's why I am thinking how to prevent them.
It seems to be evident that "asking themselves" isn't working. It must be the third time (off memory) that you notice some mess-up with cabal-version. I think this is worth some preventive measures.

And we need to fix this of course.

[fgaz]

In #9329 (comment) @phadej suggests that the criterion could be whether we touch Cabal-syntax

[phadej]

@fgaz

@phadej suggests that the criterion could be whether we touch Cabal-syntax

Except this change wasn't in Cabal-syntax, as cabal_macros.h etc generation is in Cabal (which I think is not great, as macros or extra module generation should be versioned as well).

[andreabedini]

FWIW this change https://github.com/haskell/cabal/pull/8534/files#diff-2979e1782cdde6333d50cf4ca6922117186875cafbd01007575535482b33a344 should have given away the problem ...

[Mikolaj]

Embarrassing. How do we fix it? Move the feature behind cabal-version retroactively and survey Hackage to see that no package gets broken by such a restriction? And if any gets broken, negotiate with the author to unbreak it?