Bikeshedding "recompilation avoidance"-avoidance!

[merijn]

As brought up (I think mostly by me? ;)) in #4247 and #5287 new-build aggressive caching (and my attempts to make it even more so) leads to a problem where you want things to be rebuild, but cabal-install decides it doesn't have to. For example, adding new warning flags or debug dump flags, and perhaps even more reasons I'm not considering right now.

As a result, I think we some UI/flag to force cabal-install to rebuild something. I think we'd want two flags, one that just rebuilds every local package and one to specify 1 or more local packages to be rebuild. However, I'm terrible at naming things and maybe there's other cases we'd like covered too, so please bikeshed away.

[hvr]

Well, don't you rather want cabal new-clean [<local-target(s)>] ? then we could have a mode of cabal new-clean which would only invalidate/dirty the cache (thereby causing the next new-build to call out to ghc --make, and leaving it up to GHC's recompilation check... which in the past hasn't been totally bug-free), rather than actually removing the local artifacts, i.e. cabal new-clean --invalidate-only [<local-targets>]

[23Skidoo]

+1 on @hvr's idea.

[merijn]

Like I said, I don't have any particularly strong opinions on how exactly to accomplish this. That said, the thing that bothers me about using new-clean is that something I commonly want to do in one step, i.e. "rebuild this thing" now turns into two steps. First run new-clean, then run new-build.

In fact, I see fairly little use for myself for new-clean, because I don't think "cleaning this" is ever a goal in itself while developing (unless I'm cleaning up space and just nuking dist-newstyle), so to me cleaning/invalidating is really just an obstacle between the command I actually want to run. As such, it makes more sense (to me) to think of it as a flag augmenting existing commands.

[hvr]

@merijn fair enough, but then we'll end up with multiple/redundant ways to achieve the same thing as we need to implement the primitive cabal new-clean operation in any case. But fair enough - we can do this once we have new-clean:

IOW, we would have the base functionality in

cabal new-clean [--invalidate-only] [<local-targets>...]

(NB: --invalidate-only acts non-recursive; while new-clean w/o the flag acts recursively on all reverse deps)

and then you'd have to figure out convenience flags to augment new-build which allow to prepend the new-clean action; like e.g.

cabal new-build --invalidate-local-target=foo --invalidate-local-target=bar  doo zoo

which would be equivalent to

cabal new-clean --invalidate-only foo bar
cabal new-build doo zoo

Similarly,

cabal new-build --invalidate-local-target=all doo zoo

would be equivalent to

cabal new-clean --invalidate-only all
cabal new-build doo zoo

which corresponds to your "invalidate all local packages"

Btw, note that only a proper new-clean w/o the --invalidate-only flag (or alternatively having Cabal invoke -fforce-recomp, which is more fragile IMO as it risks leaving garbage behind which may confuse cabal & ghc at some point; hence I'd rather properly clean stuff) will achieve your goal of causing ghc --make to recompile stuff when you add/remove warning flags, since GHC's recompilation avoidance check filters out warning flags as well...

[jneira]

There is an issue about adding target support for cabal clean: #7506

[ulysses4ever]

I think this should be closed as superseded by #7816. That report has a clearer formulation and a more relevant discussion.