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

Already on GitHub? Sign in to your account

cabal install should recognize if package was already configured #302

Closed
bos opened this Issue May 24, 2012 · 4 comments

Comments

Projects
None yet
2 participants
Contributor

bos commented May 24, 2012

(Imported from Trac #309, reported by bfr on 2008-07-05)

If I first configure an unpacked package inside its source directory

cabal configure --prefix=/my/path --flags=whatever

and then afterwards do

cabal install

then the configure options I gave before are not recognized by the 'cabal install'.

Instead, 'cabal install' without a package name argument should inspect whether the package is already configured and use whatever options have been set.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2008-07-05)

Checking if it is already configured is not easy in general. However we should be able to just remember what config flags were used. See #294.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-03-09)

Wed Aug 25 14:11:06 BST 2010  Dmitry Astapov <dastapov@gmail.com>
- Auto-reconfiguration when .cabal is newer than setup-config
  This patch adds "ConfigFlags" to the "LocalBuildInfo" and reuses them to
  perform "configureAction" when .cabal file is changed. This has
  the same effect as re-running "configure" with the most recent used
  set of options, which should be the sensible thing to do.
  Closes #294, #477, #309 and #518.
  
I have not yet checked if it actually fixes this ticket though. I think this one might be more tricky than the others.
Contributor

bos commented May 24, 2012

(Imported comment by @kosmikus on 2010-10-12)

I don't think this is fixed yet. At least dependency resolution happens on "cabal install", not taking previous flag choices into account. Personally, I'm not sure if "cabal install" should be as stateful as is desired here.

Contributor

ezyang commented Aug 16, 2016

Yeah, we're not going to do this.

@ezyang ezyang closed this Aug 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment