--enable-tests / --test-option(s) causes recalculation

[fommil]

Describe the bug

Repeatedly swapping between

cabal v2-build

and

cabal v2-build --enable-tests

causes a recalculation of all the dependencies (but no recompilation, after the first full build).

To Reproduce

See above

Expected behavior

I would expect (after the first full compilation) no further work by cabal.

System informataion

cabal --version
cabal-install version 2.4.1.0
compiled using version 2.4.1.0 of the Cabal library 

on any GNU/Linux with any ghc.

Additional context

My projects are quite large with multiple .cabal packages and many hackage dependencies. Hence recalculation is quite costly (e.g. 30 seconds every time the dependencies are recomputed). I'm also using a freeze file.

In addition,

cabal v2-run tasty

vs

cabal v2-run tasty --enable-tests

exhibits the same problem.

A workaround is to always use --enable-tests even when doing v2-run tasty and even though it is redundant.

I also typically use -O0 for these commands, but that's probably irrelevant (much faster dev cycle).

[hvr]

I'm afraid that what you seem to be asking is at odds with the goal for cabal v2-build (and most other v2-* commands) to be stateless; if you want to be stateful, there's cabal v2-configure -- this is the only command that's supposed to persist the configuration settings which affects the solver (by modifying or creating your cabal.project.local).

And --enable-tests is such a solver input; if you toggle it, it will require the solver to be re-run. And since you're passing --enable-tests only to v2-build which by design is supposed to not persist the settings, and be forgetful about it on the next v2-build invocation (unless you re-pass the same flags), a solver recomputation is what you'll get.

However, one thing we could do is to create a solver-cache indexed by solver inputs, so that switching between cabal v2-build --enable-tests and cabal v2-build --disable-tests would be able to retrieve a previously cached plan w/ requiring a full resolving (if and only if all solver inputs remained the same).

This would be quite general, and would allow to quickly switch between various flag settings of v2-build instantly as long as the solver input has not been trashed; however, you might still end up recompiling things in every switch between solver-inputs if the build-plans are not cleanly overlapping, as in general, switching between --enable-tests and --disable-tests is not guaranteed have this kind of overlap (in your case you're increasing the likelihood by having a freeze file, but that's a particular case and not general)

[gbaz]

I agree that a solver cache would be a very nice solution to this and related issues.

[symbiont-sam-halliday]

I'm not sure if this is the same bug or not but using --test-option(s) with v2-test also causes recalculation (in cabal-install 3.0) and it shouldn't.

[hvr]

it seems like --test-option isn't the only flag that has this effect from which one wouldn't expect this;

another one is --test-show-detail or --test-machine-log which seem to be considered input to the build-plan when modified:

File monitor 'config' unchanged.
this build was affected by the following (project) config files:
File monitor 'improved-plan' changed: monitor value changed
File monitor 'elaborated-plan' changed: monitor value changed
File monitor 'compiler' unchanged.
File monitor 'solver-plan' unchanged.
Elaborating the install plan...
File monitor 'source-hashes' unchanged.

[gbaz]

I think the only part of this not covered by the other ticket is the idea that we could have multiple cached configurations and auto-swap between them? If so we should close this and then open a new ticket for that as a possible enhancement... (It could be a significant amount of design complexity though, depending on how many configs we want to save, with what sorts of different options, etc.)