#645: cabal-install ignores --prefix ---------------------------------+------------------------------------------ Reporter: StefanK | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Description changed by StefanK: Old description:

This is not a duplicate of #601. Installing a package with

rm -rf ~/.ghc ~/.cabal cabal clean cabal configure --user --prefix="${HOME}/opt" cabal build cabal install

will install the binaries in '/home/sk/.cabal/bin' instead of '/home/sk/opt/bin'.

I'll attach a toy project demonstrating this.

System: sk@watarrka:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1

sk@watarrka:~> cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library

New description: This is not a duplicate of #601. Installing a package with {{{ rm -rf ~/.ghc ~/.cabal cabal clean cabal configure --user --prefix="${HOME}/opt" cabal build cabal install }}} will install the binaries in '/home/sk/.cabal/bin' instead of '/home/sk/opt/bin'. I'll attach a toy project demonstrating this. System: {{{ sk@watarrka:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 sk@watarrka:~> cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library }}} -- -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/645#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#645: confusing interface: cabal "install" subcommand has two clashing meanings ---------------------------------+------------------------------------------ Reporter: StefanK | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by StefanK): Replying to [comment:2 duncan]:

So it will work as expected if you do: {{{ cabal clean cabal install --user --prefix="${HOME}/opt" }}}

The question is how we reconcile these two meanings. One might imagine

Thank you very much, that worked. that we could tell if the package is already configured and not- reconfigure. In general, for an arbitrary build system that's not really possible.

Suggestions welcome.

This is what I personally would expect from a user's perspective: The order of precedence should be: 1. command line arguments. 2. previous run of {{{cabal configure}}}. 3. The user's {{{~/.cabal/config}}}. 4. Maybe some global setting, e.g., {{{/etc/cabal/config}}}. 5. Cabal's builtin defaults. An algorithm to achieve this for {{{cabal install}}} would be reading the sources in reverse order, each read overwriting settings from a previous read, silently skipping sources that don't exist: 1. Initialise with builtin settings. 2. If {{{/etc/cabal/config}}} exists read it, and adopt everything it says. 3. If {{{~/.cabal/config}}} exists read it, and adopt everything it says. 4. If there was a previous {{{cabal configure}}} read it, and adopt everything it says. If we cannot determine whether there was a previous configure, act as if there was none. 5. Read command line arguments, and adopt everything they say. An algorithm for cabal configure would work identically, i.e., reuse settings from a previous cabal configure. Of course, cabal clean should remove settings provided by a previous cabal configure. Kind regards, Stefan -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/645#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects