"configuration changed" is way too vague

[9999years]

In order, the following will be built:
 - my-0.1 (lib:my) (configuration changed)

What do you mean the configuration changed? How did the configuration change?

[geekosaur]

The ghost of #9476 walks again!

[philderbeast]

This is the error I'm seeing in a CI run, https://github.com/haskell/cabal/actions/runs/12138982850/job/33845593860?pr=10546, that I'm not seeing when I run the same test locally (on Windows):

Actual output differs from expected:

stderr:
--- "D:\\a\\_temp\\cabal-testsuite-9832\\cabal.dist\\cabal.out.normalized"	2024-12-03 12:34:26.194758500 +0000
+++ "D:\\a\\_temp\\cabal-testsuite-9832\\cabal.dist\\cabal.comp.out.normalized"	2024-12-03 12:34:26.193763000 +0000
@@ -651,7 +651,12 @@
     imported by: woops/woops-1.config
     imported by: woops-0.project
 Resolving dependencies...
-Up to date
+Build profile: -w ghc-<GHCVER> -O1
+In order, the following will be built:
+ - my-0.1 (lib:my) (configuration changed)
+Configuring my-0.1...
+Preprocessing library for my-0.1...
+Building library for my-0.1...
 # checking "using config from message" without URI imports
 # cabal v2-build
 # checking "using config from message" with URI imports

*** unexpected failure for PackageTests\ConditionalAndImport\cabal.test.hs

[geekosaur]

And that's pretty much what I was thinking of; I've seen it in CI as well.

[philderbeast]

@geekosaur, I was seeing this with #10546. I was using the same project twice in cabal-testsuite/PackageTests/ConditionalAndImport/cabal.test.hs. Using the project only once avoids the problem.

I was accessing the same project from two different directories:

  log "checking if we detect when the same config is imported via many different paths (we don't)"
  woopping <- cabal' "v2-build" [ "--project-file=woops-0.project" ]

  log "checking \"using config from message\" with URI imports"
  withDirectory "woops" $ do
    woopping <- fails $ cabal' "v2-build" [ "--dry-run", "--project-file=../woops-0.project" ]

    -- Use assertRegex when the output is tainted by the temp directory, like
    -- this:
    --
    --   When using configuration from:
    --   - /tmp/cabal-testsuite-282695/woops-0.project
    --   - /tmp/cabal-testsuite-282695/woops-2.config etc
    assertRegex
      "Project configuration with URI imports is listed in full"
      "When using configuration from:(\n|\r\n) \
        \ .*woops-0\\.project(\n|\r\n) \
        \ .*with-ghc\\.config(\n|\r\n) \
        \ .*woops-2\\.config(\n|\r\n) \
        \ .*woops-4\\.config(\n|\r\n) \
        \ .*woops-6\\.config(\n|\r\n) \
        \ .*woops-8\\.config(\n|\r\n) \
        \ .*woops-1\\.config(\n|\r\n) \
        \ .*woops-3\\.config(\n|\r\n) \
        \ .*woops-5\\.config(\n|\r\n) \
        \ .*woops-7\\.config(\n|\r\n) \
        \ .*woops-9\\.config(\n|\r\n) \
        \ .*https://www.stackage.org/lts-21.25/cabal.config(\n|\r\n)"
      woopping

    assertOutputContains
      "The following errors occurred: \
      \  - The package directory '.' does not contain any .cabal file."
      woopping

    return ()

[geekosaur]

Thing is, I occasionally see it with tests that weren't changed by the PR, and generally on only one platform.

[9999years]

@philderbeast For an example spurious 'configuration changed', see: #10524 (comment).

Excerpt (NB this is about code in #10524, not code on master):

The package configuration now includes the project file path:

ElaboratedConfiguredPackage
    { elabUnitId = UnitId "my-0.1-inplace"
    -- ...
    , elabPkgSourceLocation = WithConstraintSource
        { constraintInner = LocalUnpackedPackage "<ROOT>/."
        , constraintSource = ConstraintSourceProjectConfig
            ( ProjectConfigPath
                ( "noncyclical-same-filename-a.project" :| [] )
            )
        }
    -- ...
    }

Therefore, when we rebuild with a different --project-file, it changes the configuration.

[philderbeast]

Thanks @9999years. Putting related tests in the same folder using projects seems risky.

[9999years]

So this happens when the full, expanded configuration changes. This could mean a lot of things! Here's an easy solution: we write an ediff of the old and new values to a file under dist-newstyle and print the path to that file so anyone interested in debugging "configuration changed" can cat it.

Or we could just write a "describe configured package diff" function, which maybe wouldn't be too hard?