Bridging the gap between cabal's rebuild logic and end-users

[Kleidukos]

A question I often ask myself after having switched to another branch at work is "Why do my dependencies need to be rebuilt?".

As an end-user I have the following output:

Configuration is affected by the following files:
- cabal.project
- cabal.project.freeze
- cabal.project.local
Build profile: -w ghc-9.6.6 -O1
In order, the following will be built (use -v for more details):
 - barbies-2.1.1.0 (lib) (requires build)
 - comonad-5.0.8 (lib) (requires build)
 - data-default-0.7.1.1 (lib:data-default) (requires build)
[…]
 - my-project-1.0 (lib)  --enable-profiling (configuration changed)

And now I have to rebuild all of the 333 dependencies (direct & transitive) of the project.

My cabal.project.local file looks like this:

ignore-project: False
with-compiler: ghc-9.6
profiling: True
profiling-detail: all-functions

And (I must stress this) always remains the same between branches.

Is cabal unable to preserve the cache of a build with profiling? Can I somehow make it spill the beans as to why a cache has to be invalidated? This would be a great improvement for projects that have a consequent amount of total dependencies.

[Kleidukos]

I also put -ddump-deriv in one of my files, in order to debug a FromJSON instance, although I doubt this would have triggered everything to rebuild.

Ultimately I'm not looking for a specific answer to my problem right now, but rather I'd like to put on the table "more observability regarding why the cache gets busted".