I shouldn't have to manually re-run `cabal configure`

[bitemyapp]

[callen@localhost ~/code/bloodhound]$ cabal repl
cabal: You need to re-run the 'configure' command. The version of Cabal being
used has changed (was Cabal-1.20.0.0, now Cabal-1.20.0.1). Additionally the
compiler is different (was ghc-7.8, now ghc-7.6) which is probably the cause
of the problem.
[callen@localhost ~/code/bloodhound]$ cabal configure
Resolving dependencies...
Configuring bloodhound-0.4.0.0...
[callen@localhost ~/code/bloodhound]$ cabal repl
Preprocessing library bloodhound-0.4.0.0...
[1 of 4] Compiling Database.Bloodhound.Types.Class ( Database/Bloodhound/Types/Class.hs, dist/build/Database/Bloodhound/Types/Class.o )
[2 of 4] Compiling Database.Bloodhound.Types ( Database/Bloodhound/Types.hs, dist/build/Database/Bloodhound/Types.o )

Easily in the realm of "just do it". Users shouldn't have to fuss with this.

+1

[yogsototh]

+1

[YoEight]

+1

[bitemyapp]

Additional example:

[callen@cumae ~/work/bloodhound]$ cabal test
cabal: You need to re-run the 'configure' command. The version of Cabal being
used has changed (was Cabal-1.20.0.2, now Cabal-1.20.0.1).
[callen@cumae ~/work/bloodhound]$ cabal configure --enable-tests
Resolving dependencies...
Configuring bloodhound-0.4.0.0...
[callen@cumae ~/work/bloodhound]$ cabal test                    
Building bloodhound-0.4.0.0...
Preprocessing library bloodhound-0.4.0.0...
[2 of 4] Compiling Database.Bloodhound.Types ( Database/Bloodhound/Types.hs, dist/build/Database/Bloodhound/Types.o )

[rgrinberg]

Yes please. +12312738912. Looks like @bitemyapp will be cabal's usability expert after that conversation with Paul Phillips :D

[ttuegel]

Some design notes:

There are two cases we need to cover.

1. "The version of Cabal being used has changed." The LocalBuildInfo format can change dramatically between versions, so it is not sufficient to look up the ConfigFlags from dist/setup-config. I propose we store the flags in dist/setup-config-flags in a backward- and forward-compatible format. The format used by the cabal.config parser should do nicely, we just need to ignore unrecognized fields. We probably want to move that parser to Cabal; the setup/cabal behavior has been getting pretty divergent lately. We'll need a pretty printer if that module doesn't have one already.
2. If the old version of Cabal was too old to write dist/setup-config-flags, we will have to try parsing the setup-config anyway. I made some changes for improve dist/setup-config format mismatch detection #2251 so we can now at least attempt to parse old files. With the new binary setup-config coming, we may want to keep around the oldest text setup-config format so we can bridge the gap.

[mietek]

It would be nice to have this fixed.

[ttuegel]

Working on this now. I have changed my mind about how this should be implemented. We need to save the flags given to configure in a totally version independent way, so I'm just going to serialize the result of getArgs into dist/setup-config-flags. When we need to reconfigure, we'll just invoke main with the saved arguments using withArgs. This may still fail between versions when the command-line interface changes, but that happens only rarely. (Even that failure should give reasonable error messages.)