Changing a file imported by cabal.project does not trigger recompilation

[mpickering]

It seems that changes to imported cabal.project fragments do not trigger rebuilds correctly.

Reproducer: https://github.com/mpickering/solid-eureka

In this project there are two packages, a and b, if you add package b to the pkgs.project fragment then it is not picked up until you add a blank line to the cabal.project.

• cabal build exe:b -- Observe failure
• Modify pkgs.project to add b
• cabal build exe:b -- Observe failure
• Modify cabal.project by adding a newline
• cabal build exe:b -- Observe success

This affects cabal development due to the many uses of imports.

[philderbeast]

Reproducible with cabal-install-3.12.1.0 but not with cabal-install-3.10.3.0. Here's the behaviour¹ with cabal-install-3.10.3.0:

$ git remote -v
origin	git@github.com:mpickering/solid-eureka.git (fetch)
origin	git@github.com:mpickering/solid-eureka.git (push)

$ git reset --hard
HEAD is now at 3a371c0 init

$ cabal build exe:b
Error: cabal: Internal error in target matching: could not make an unambiguous
fully qualified target selector for 'exe:b'.
We made the target 'exe:b' (unknown-component) that was expected to be
unambiguous but matches the following targets:
'exe:b', matching:
- exe:b (unknown-component)
- :pkg:exe:lib:exe:file:b (unknown-file)

Note: Cabal expects to be able to make a single fully qualified name for a
target or provide a more specific error. Our failure to do so is a bug in
cabal. Tracking issue: https://github.com/haskell/cabal/issues/8684

Hint: this may be caused by trying to build a package that exists in the
project directory but is missing from the 'packages' stanza in your cabal
project file.

$ echo "packages: a, b" > pkgs.project

$ cabal build exe:b
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: a-0.1.0.0 (user goal)
[__1] next goal: base (dependency of a)
[__1] rejecting: base-4.19.1.0/installed-c38a (conflict: a => base^>=4.20.0.0)
[__1] rejecting: base-4.20.0.1, base-4.20.0.0, base-4.19.1.0, base-4.19.0.0,
base-4.18.2.1, base-4.18.2.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.1,
base-4.17.2.0, base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0,
base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0,
base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0,
base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0,
base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0,
base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0,
base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0,
base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0,
base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable
package requires installed instance)
[__1] fail (backjumping, conflict set: a, base)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, a

$ cabal --version
cabal-install version 3.10.3.0
compiled using version 3.10.3.0 of the Cabal library

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.8.2

Footnotes

1. The reproducer project packages are set up for base ^=4.20.0.0 (so ghc-9.10.1) but we're only testing whether a package is included in the project so a constraint failure is as good as a successful build. ↩

[sol]

I just ran into this when trying to move some things from cabal.project to separate files.

This bug limits the utility of import quite a bit.

[Bodigrim]

Same here, quite an annoying regression.

[ulysses4ever]

oh, is it a regression @Bodigrim ?? I thought it never worked.

[sol]

Reproducible with cabal-install-3.12.1.0 but not with `cabal-install-3.10.

@ulysses4ever

[ulysses4ever]

ah, my bad. Would be good to bisect...

[philderbeast]

I did the bisect and the commit that stops triggering recompilation is f8cd563, from #9578.

[ulysses4ever]

@philderbeast terrific! Do you think you could submit a fix?