Skip to content

cabal install should change directory before building a local package #1236

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

Closed
dmwit opened this issue Mar 13, 2013 · 12 comments
Closed

cabal install should change directory before building a local package #1236

dmwit opened this issue Mar 13, 2013 · 12 comments

Comments

@dmwit
Copy link
Collaborator

dmwit commented Mar 13, 2013

When using cabal-install to install a local package (by which I mean one which is unpacked and sitting in a directory on the hard drive), cabal should cd into the directory the package is in before attempting to configure/build it, so that local resources are available via relative paths. I've put a minimal package which demonstrates the problem at http://dmwit.com/tmp.tar.gz; unpack the tar and compare the output of the following two commands:

cd tmp/foo && cabal install && cd -
cabal install tmp/foo

The former succeeds; the latter fails.

This is biting me in gtk2hs, where I sometimes wish to re-install several packages with a command like "cabal install ./cairo ./gtk" rather than the more unwieldy and fragile "cd cairo && cabal install --force-reinstalls && cd ../gtk && cabal install && cd ..".

@23Skidoo
Copy link
Member

Couldn't reproduce (both 0.14 and the git version work fine):

$ cabal install tmp/foo
Resolving dependencies...
[1 of 1] Compiling Main             ( tmp/foo/Setup.hs, tmp/foo/dist/setup/Main.o )
Linking tmp/foo/dist/setup/setup ...
Configuring foo-0.0...
Building foo-0.0...
Preprocessing library foo-0.0...
Registering foo-0.0...
Installing library in /home/cabal-test/.cabal/lib/foo-0.0/ghc-7.4.2
Registering foo-0.0...
Installed foo-0.0

@dmwit
Copy link
Collaborator Author

dmwit commented Mar 15, 2013

Hm. It doesn't work here. Transcript enclosed below. I'll try fresh from git and report back.

crabgrass:~% cabal --version
cabal-install version 1.16.0
using version 1.16.0 of the Cabal library 
crabgrass:~% ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.1
crabgrass:~% wget http://dmwit.com/tmp.tar.gz
--2013-03-15 09:52:04--  http://dmwit.com/tmp.tar.gz
Resolving dmwit.com (dmwit.com)... 69.90.123.70
Connecting to dmwit.com (dmwit.com)|69.90.123.70|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 584 [application/x-gzip]
Saving to: ‘tmp.tar.gz’

100%[=====================================================================================>] 584         --.-K/s   in 0s      

2013-03-15 09:52:04 (77.0 MB/s) - ‘tmp.tar.gz’ saved [584/584]

crabgrass:~% tar xf tmp.tar.gz 
crabgrass:~% cabal install tmp/foo
Warning: The package list for 'hackage.haskell.org' is 17 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
In order, the following will be installed:
foo-0.0 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
[1 of 1] Compiling Main             ( tmp/foo/Setup.hs, tmp/foo/dist/setup/Main.o )
Linking tmp/foo/dist/setup/setup ...
Failed to install foo-0.0
cabal: Error: some packages failed to install:
foo-0.0 failed during the configure step. The exception was:
ExitFailure 127
zsh: exit 1     cabal install tmp/foo

@23Skidoo
Copy link
Member

Maybe it was just a 1.16 bug?

@dmwit
Copy link
Collaborator Author

dmwit commented Mar 15, 2013

Hm. I can't build the given package at all with cabal-install from git, though it seems to be a different problem.

crabgrass:~/tmp/foo% cabal --version
cabal-install version 1.17.0
using version 1.17.0 of the Cabal library 
crabgrass:~/tmp/foo% cabal install
Warning: The package list for 'hackage.haskell.org' is 17 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
In order, the following will be installed:
foo-0.0 (latest: 1.0) (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
[1 of 1] Compiling Main             ( Setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
Configuring foo-0.0...
Building foo-0.0...
Preprocessing library foo-0.0...
In-place registering foo-0.0...
setup: foo-0.0: Warning: haddock-interfaces:
/home/dmwit/tmp/foo/dist/doc/html/foo/foo.haddock doesn't exist or isn't a
file
foo-0.0: Warning: haddock-html: /home/dmwit/tmp/foo/dist/doc/html/foo doesn't
exist or isn't a directory
foo-0.0: cannot find libHSfoo-0.0.a on library path (use --force to override)
Failed to install foo-0.0
cabal: Error: some packages failed to install:
foo-0.0 failed during the building phase. The exception was:
ExitFailure 1
zsh: exit 1     cabal install

I have changed from "documentation: True" to "documentation: False" in ~/.cabal/config and added --disable-documentation, but this error persists. I'll try again in a few days, and when I can build the package from within the directory, I'll let you know if I can build from outside the directory.

@dmwit
Copy link
Collaborator Author

dmwit commented Mar 15, 2013

Oh, and I just noticed the "use --force to override" suggestion; --force doesn't fix it, either.

@23Skidoo
Copy link
Member

Strange. Maybe it's a configuration issue? I tried toggling various settings (like split-objs, documentation, jobs etc), but the package still builds fine. Can you post your ~/.cabal/config? And by the way, which OS are you on?

@dmwit
Copy link
Collaborator Author

dmwit commented Mar 15, 2013

crabgrass:~% uname -a
Linux crabgrass 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
crabgrass:~% grep -v 'password\\|--\\|^$' .cabal/config
remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
remote-repo-cache: /home/dmwit/.cabal/packages
library-profiling: True
documentation: False
doc-index-file: $datadir/doc/index.html
build-summary: /home/dmwit/.cabal/$arch/logs/build.log
remote-build-reporting: anonymous
username: DanielWagner
install-dirs user
  prefix: /home/dmwit/.cabal/$arch
install-dirs global

@byorgey
Copy link
Member

byorgey commented Mar 15, 2013

For the record, I can't reproduce either -- it installs fine for me with both 1.16 and HEAD cabal-install. Can you try running cabal install -v3? It might give us more clues about what is failing.

@dmwit
Copy link
Collaborator Author

dmwit commented Mar 15, 2013

Okay, I've split off the discussion of the problem I'm having with the most recent version from git into issue 1241. For the following, I'll report what happens with non-git cabal-install.

crabgrass:~/tmp% cabal --version
cabal-install version 1.16.0
using version 1.16.0 of the Cabal library 
crabgrass:~/tmp% cabal install -v3 foo/
searching for ghc in path.
found ghc at /usr/local/bin/ghc
("/usr/local/bin/ghc",["--numeric-version"])
/usr/local/bin/ghc is version 7.6.1
looking for tool "ghc-pkg" near compiler in /usr/local/bin
found ghc-pkg in /usr/local/bin/ghc-pkg
("/usr/local/bin/ghc-pkg",["--version"])
/usr/local/bin/ghc-pkg is version 7.6.1
("/usr/local/bin/ghc",["--supported-languages"])
("/usr/local/bin/ghc",["--info"])
Reading installed packages...
("/usr/local/bin/ghc-pkg",["dump","--global","-v0"])
("/usr/local/bin/ghc-pkg",["dump","--user","-v0"])
("/usr/local/bin/ghc",["--print-libdir"])
Reading available packages...
Warning: The package list for 'hackage.haskell.org' is 18 days old.
Run 'cabal update' to get the latest list of available packages.
Choosing modular solver.
Resolving dependencies...
[__0] rejecting: foo-1.0 (global constraint requires ==0.0)
[__0] trying: foo-0.0
[__1] done
In order, the following will be installed:
foo-0.0 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Ready to install foo-0.0
Waiting for install task to finish...
Using external setup method with build-type Custom
creating foo/dist/setup
Using Cabal library version 1.16.0
Using foo/Setup.hs as setup script.
foo/dist/setup/setup configure --verbose=3 --ghc
--prefix=/home/dmwit/.cabal/$arch --enable-library-profiling --user
--disable-tests --disable-benchmarks
Failed to install foo-0.0
cabal: Error: some packages failed to install:
foo-0.0 failed during the configure step. The exception was:
ExitFailure 127
zsh: exit 1     cabal install -v3 foo/

@byorgey
Copy link
Member

byorgey commented Mar 15, 2013

Hmm, odd how the output just stops after calling foo/dist/setup/setup configure .... When I run the same command (cabal install foo/ -v3) the
output I see is

...
Using foo/Setup.hs as setup script.
foo/dist/setup/setup configure --verbose=3 --ghc
--prefix=/home1/b/byorgey/local --user --disable-tests --disable-benchmarks
Redirecting build log to {handle: /home1/b/byorgey/.cabal/logs/foo-0.0.log}
Building foo-0.0...
...

Note also that if I try running this command directly, I get an error about
bar:

LVN513-9 :: ~/tmp/tmp » foo/dist/setup/setup configure --verbose=3 --ghc
--prefix=/home1/b/byorgey/local --user --disable-tests --disable-benchmarks
setup: bar: openFile: does not exist (No such file or directory)

so it seems like cabal really is setting the current directory to foo
before calling the setup script.

I wonder if the $arch bit in your command line (from your prefix field)
is getting interpreted in some funny way by your shell? Note that directly
running the setup script like this is triggered by having build-type: Custom, so I wonder what happens if you make a package with build-type: Custom but nothing in the Setup script that actually depends on the
current directory, just main = defaultMain?

@dmwit
Copy link
Collaborator Author

dmwit commented Mar 15, 2013

Just sat down with Brent. Some things we discovered:

  • top order bit: this bug doesn't appear in 1.16.0.2, so may be worth closing this issue
  • it has nothing to do with the working directory: the compiled setup program just never runs
  • in the log, cabal claims to run the program "foo/dist/...", so we thought perhaps the extra "foo/" was a problem -- but by symlinking "foo/foo" to "foo/dist", we discovered this was not it
  • the $arch thing is probably a red herring as well: we changed this to a literal directory, and the same problem happened

@byorgey
Copy link
Member

byorgey commented Mar 15, 2013

Looks like this was fixed in 1.16.0.2 by 48082b9. Closing as duplicate of #1058.

@byorgey byorgey closed this as completed Mar 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants