New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bitemyapp opened this Issue Nov 12, 2014 · 18 comments

Comments

@bitemyapp
Copy link
Contributor

bitemyapp commented Nov 12, 2014

[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.

@freebroccolo

This comment has been minimized.

Copy link

freebroccolo commented Nov 13, 2014

+1

2 similar comments
@yogsototh

This comment has been minimized.

Copy link

yogsototh commented Nov 13, 2014

+1

@YoEight

This comment has been minimized.

Copy link

YoEight commented Nov 13, 2014

+1

@bitemyapp

This comment has been minimized.

Copy link
Contributor

bitemyapp commented Nov 20, 2014

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

This comment has been minimized.

Copy link

rgrinberg commented Nov 20, 2014

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

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Dec 9, 2014

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 #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.

@ttuegel ttuegel self-assigned this Dec 9, 2014

@mietek

This comment has been minimized.

Copy link
Contributor

mietek commented Jan 5, 2015

It would be nice to have this fixed.

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Jan 5, 2015

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.)

@bitemyapp

This comment has been minimized.

Copy link
Contributor

bitemyapp commented Jun 11, 2015

@ttuegel is this resolved or still pending for cabal-install-1.24?

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Jun 12, 2015

I'm still working on this. (I almost fell into the yak-shaving trap, implementing a feature that would make this one easier to implement.)

@bitemyapp

This comment has been minimized.

Copy link
Contributor

bitemyapp commented Jun 12, 2015

@ttuegel cool, thank you :)

@bitemyapp

This comment has been minimized.

Copy link
Contributor

bitemyapp commented Jun 19, 2015

I'm getting a permanent, "you need to reconfigure" message.

boura:bloodhound callen$ cabal configure --enable-tests
Resolving dependencies...
Configuring bloodhound-0.6.0.0...

boura:bloodhound callen$ cabal test
cabal: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.18.1.5, now Cabal-1.22.3.0).

boura:bloodhound callen$ cabal --version
cabal-install version 1.22.4.0
using version 1.22.3.0 of the Cabal library

boura:bloodhound callen$ cabal sandbox hc-pkg list Cabal
/Applications/ghc-7.8.4.app/Contents/lib/ghc-7.8.4/package.conf.d
   Cabal-1.18.1.5
/Users/callen/work/bloodhound/.cabal-sandbox/x86_64-osx-ghc-7.8.4-packages.conf.d

Pretty annoying. Is there a ticket for this already? I saw some related'ish looking things like

#2633

/cc @ttuegel @tibbe

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Jun 19, 2015

@bitemyapp This is a build-type: Custom package, right? The problem is a version mismatch between cabal-install's Cabal library and the installed Cabal. cabal-install needs to read the saved build config (for the DWIM logic in cabal test) but that info is produced by the installed Cabal with build-type: Custom packages. (FWIW I'm moving that logic down into Cabal.)

It should suffice to install Cabal-1.22.3.0 in your sandbox. cabal-install should be doing that automatically; I'll see if there's a ticket for that.

@bitemyapp

This comment has been minimized.

Copy link
Contributor

bitemyapp commented Jun 19, 2015

@ttuegel Yep, custom, but I can't get it to install Cabal in the sandbox.

boura:bloodhound callen$ cabal install Cabal==1.22.3.0
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: doctest-0.10.0/installed-bfa... (user goal)
trying: ghc-7.8.4/installed-436... (dependency of
doctest-0.10.0/installed-bfa...)
next goal: Cabal (user goal)
rejecting: Cabal-1.22.4.0 (global constraint requires ==1.22.3.0)
rejecting: Cabal-1.22.3.0 (conflict: ghc => Cabal==1.18.1.5/installed-c52...)
rejecting: Cabal-1.22.2.0, 1.22.1.1, 1.22.1.0, 1.22.0.0, 1.20.0.3, 1.20.0.2,
1.20.0.1, 1.20.0.0, 1.18.1.6, 1.18.1.5/installed-c52..., 1.18.1.5, 1.18.1.4,
1.18.1.3, 1.18.1.2, 1.18.1.1, 1.18.1, 1.18.0, 1.16.0.3, 1.16.0.2, 1.16.0.1,
1.16.0, 1.14.0, 1.12.0, 1.10.2.0, 1.10.1.0, 1.10.0.0, 1.8.0.6, 1.8.0.4,
1.8.0.2, 1.6.0.3, 1.6.0.2, 1.6.0.1, 1.4.0.2, 1.4.0.1, 1.4.0.0, 1.2.4.0,
1.2.3.0, 1.2.2.0, 1.2.1, 1.1.6 (global constraint requires ==1.22.3.0)
Dependency tree exhaustively searched.

Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
boura:bloodhound callen$ cabal install Cabal==1.22.4.0
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: doctest-0.10.0/installed-bfa... (user goal)
trying: ghc-7.8.4/installed-436... (dependency of
doctest-0.10.0/installed-bfa...)
next goal: Cabal (user goal)
rejecting: Cabal-1.22.4.0 (conflict: ghc => Cabal==1.18.1.5/installed-c52...)
rejecting: Cabal-1.22.3.0, 1.22.2.0, 1.22.1.1, 1.22.1.0, 1.22.0.0, 1.20.0.3,
1.20.0.2, 1.20.0.1, 1.20.0.0, 1.18.1.6, 1.18.1.5/installed-c52..., 1.18.1.5,
1.18.1.4, 1.18.1.3, 1.18.1.2, 1.18.1.1, 1.18.1, 1.18.0, 1.16.0.3, 1.16.0.2,
1.16.0.1, 1.16.0, 1.14.0, 1.12.0, 1.10.2.0, 1.10.1.0, 1.10.0.0, 1.8.0.6,
1.8.0.4, 1.8.0.2, 1.6.0.3, 1.6.0.2, 1.6.0.1, 1.4.0.2, 1.4.0.1, 1.4.0.0,
1.2.4.0, 1.2.3.0, 1.2.2.0, 1.2.1, 1.1.6 (global constraint requires
==1.22.4.0)
Dependency tree exhaustively searched.

Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
boura:bloodhound callen$ cabal install Cabal
Resolving dependencies...
All the requested packages are already installed:
Cabal-1.18.1.5
Use --reinstall if you want to reinstall anyway.
boura:bloodhound callen$ cabal install Cabal --reinstall
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: doctest-0.10.0/installed-bfa... (user goal)
next goal: ghc (dependency of doctest-0.10.0/installed-bfa...)
rejecting: ghc-7.8.4/installed-436... (package is broken)
Dependency tree exhaustively searched.

Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
boura:bloodhound callen$ cabal install Cabal==1.22.3.0 --allow-newer
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: doctest-0.10.0/installed-bfa... (user goal)
trying: ghc-7.8.4/installed-436... (dependency of
doctest-0.10.0/installed-bfa...)
next goal: Cabal (user goal)
rejecting: Cabal-1.22.4.0 (global constraint requires ==1.22.3.0)
rejecting: Cabal-1.22.3.0 (conflict: ghc => Cabal==1.18.1.5/installed-c52...)
rejecting: Cabal-1.22.2.0, 1.22.1.1, 1.22.1.0, 1.22.0.0, 1.20.0.3, 1.20.0.2,
1.20.0.1, 1.20.0.0, 1.18.1.6, 1.18.1.5/installed-c52..., 1.18.1.5, 1.18.1.4,
1.18.1.3, 1.18.1.2, 1.18.1.1, 1.18.1, 1.18.0, 1.16.0.3, 1.16.0.2, 1.16.0.1,
1.16.0, 1.14.0, 1.12.0, 1.10.2.0, 1.10.1.0, 1.10.0.0, 1.8.0.6, 1.8.0.4,
1.8.0.2, 1.6.0.3, 1.6.0.2, 1.6.0.1, 1.4.0.2, 1.4.0.1, 1.4.0.0, 1.2.4.0,
1.2.3.0, 1.2.2.0, 1.2.1, 1.1.6 (global constraint requires ==1.22.3.0)
Dependency tree exhaustively searched.

Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
boura:bloodhound callen$ cabal install Cabal==1.22.3.0 --allow-newer --force-reinstalls --reinstall
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: doctest-0.10.0/installed-bfa... (user goal)
next goal: ghc (dependency of doctest-0.10.0/installed-bfa...)
rejecting: ghc-7.8.4/installed-436... (package is broken)
Dependency tree exhaustively searched.

Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Jun 19, 2015

OK, here is the problem:

...
trying: doctest-0.10.0/installed-bfa... (user goal)
trying: ghc-7.8.4/installed-436... (dependency of doctest-0.10.0/installed-bfa...)
next goal: Cabal (user goal)
rejecting: Cabal-1.22.4.0 (global constraint requires ==1.22.3.0)
rejecting: Cabal-1.22.3.0 (conflict: ghc => Cabal==1.18.1.5/installed-c52...)
...

This says:

  1. bloodhound needs doctest
  2. doctest needs the ghc library
  3. the ghc library needs the Cabal library that shipped with the compiler
  4. conflict: the Cabal that ships with ghc is not the Cabal you asked for.

IOW, it's the basic diamond-dependency Cabal-hell problem. IIRC, newer ghc versions do not link to Cabal, so they do not have this restriction, but that doesn't really help since ghc-7.10 has those performance regressions.

The only workaround I can think of ATM is to build the custom setup manually, i.e. ghc --make Setup.hs. Then you can ./Setup configure --enable-tests, ./Setup build, and ./Setup test. You may be able to use the sandbox if you configure with --package-db=.cabal-sandbox/${arch}-ghc-${version}-packages.conf.d. (I am aware that this is deeply unsatisfying, even if it works.)

@bitemyapp

This comment has been minimized.

Copy link
Contributor

bitemyapp commented Jun 19, 2015

@ttuegel

since ghc-7.10 has those performance regressions.

er, what performance regressions?

I'll try the manual setup build, thank you!

Update: that got me going. Now to attack other problems 👍 🐻 🌳

@ttuegel

This comment has been minimized.

Copy link
Member

ttuegel commented Sep 20, 2015

I have a work-in-progress/preview in PR #2829.

@23Skidoo 23Skidoo modified the milestones: cabal-install 1.24, cabal-install 1.26 Feb 21, 2016

@ezyang

This comment has been minimized.

Copy link
Contributor

ezyang commented Sep 6, 2016

@ttuegel and I had a chat about the state of this bug, here are some notes:

  • @ttuegel has agreed that this can make it's way into the next feature release
  • There was some miscommunication about how this feature interacts with new-build, but we came to an agreement that reconfigure would not be exercised by a new-build style build system, because the build system always knows what the necessary set of configuration flags are, and will just call Setup configure as necessary. (Similarly, Stack wouldn't benefit from reconfigure since if the Cabal library version changes, you're rebuilding the world anyway.)
  • Reconfigure will still help people using old-style build/sandboxes
  • new-build will NOT be default in 2.0, and given that the patch is very nearly complete (it is missing some wiring up on the cabal-install side, and a cabal-install wrapper for the reconfigure command), it makes sense to help out users for at least one feature release avoid this problem

ttuegel added a commit to ttuegel/cabal that referenced this issue Sep 10, 2016

ttuegel added a commit to ttuegel/cabal that referenced this issue Sep 10, 2016

Add `reconfigure` command
Fixes haskell#2214 by adding a `reconfigure` command and invoking it whenever
necessary. The last configure flags used are saved in a
version-independent format so it should never be necessary for the user
to reconfigure manually.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment