I installed a custom Haskell toolchain with the prefix $HOME/usr, so the compiler lives in $HOME/usr/bin/ghc and the documentation in $HOME/usr/share/doc/ghc/.... The toolchain consists of a ghc installation, a cabal installation and all the libs you need. I set up $PATH in a way, that all these programs are in it. There is no other installation of these tools on my system.
Now I tried to install some other libraries. But I always got the same error when cabal tried to install the documentation:
~$ cabal install --global binary
Resolving dependencies...
Configuring binary-0.5.0.2...
Preprocessing library binary-0.5.0.2...
Building binary-0.5.0.2...
... snip ...
Registering binary-0.5.0.2...
cabal: /usr/local/share/doc: permission denied
How can I tell cabal where the documentation should live? I don't want to give this information again and again in the shell, so the best would be a config file. I want to have all the haskell related stuff in my home tree, to avoid destroying my system with a wrong command.
Why are you installing with "--global"? By default this would put everything in /usr/local/. If you do a standard per-user install the docs will be installed into your home directory and it should work fine.
That being said, this is configurable via a file. The cabal config file is typically located at ~/.cabal/config/. Here's the relevant section of mine:
install-dirs global
-- prefix: /usr/local
-- bindir: $prefix/bin
-- libdir: $prefix/lib
-- libsubdir: $pkgid/$compiler
-- libexecdir: $prefix/libexec
-- datadir: $prefix/share
-- datasubdir: $pkgid
-- docdir: $datadir/doc/$pkgid
-- htmldir: $docdir/html
-- haddockdir: $htmldir
You can make whatever changes you like, just be sure to uncomment the lines. There is also an "install-dirs user" section, which is used in per-user installs.
I agree with the poster. Why is there no clear documentation for how to do
cabal install package --global
that prompts for sudo when permission is needed?
Doing
sudo cabal install package
is a bad idea because then you're building packages as root. And you have to allow an internet connection to write to a file owned by root (you will have to populate /root/.cabal or something like that).
Here is a good reason why one would want to do this:
If I install ghc and the haskell platform through my linux package manager (there are good reasons for this ;), then if I do cabal install package
it will not recognize the packages that globally recognized.
Well, someone actually posted a(n almost annoyingly) detailed description of how to do global installations (with either --global or install-dirs global) without running into permission errors. The trick is to use root-cmd sudo in the cabal config file.
See,
http://jdgallag.wordpress.com/2011/05/14/cabal-install-to-global-using-sudo-but-do-not-build-as-root/
Related
In the Cabal User Guide it says that Cabal is often compared with autoconf and automake since the command line interface for actually configuring and building packages follows the same steps steps:
./configure --prefix=...
make
make install
compared to
cabal configure --prefix=...
cabal build
cabal install
My understanding is that ./configure uses a config file (produced by autoconf) to adapt the make process to the environment in which it will run and also to check dependencies. So ./configure therefore always have an "input" to conform to. But if cabal configure is not given any arguments what does it do, and why is it necessary before running cabal build?
The cabal configure step does at least two things I know of:
Check that the package description parses OK.
Check that all required dependencies are already installed (and report an error if not).
Basically it's running the constraint solver to decide exactly which packages you're going to build against. (E.g., if you have several versions of ByteString installed, which version are you going to use? Well it might depend on which version the packages you depend on are expecting...)
Also I believe it's possible to supply options at configure time which change exactly which features of the package get built (but I don't have experience with this).
I think originally you had to call configure before you could call build, but I believe now the cabal command-line tool does that step for you automatically in many cases. (E.g., cabal run now seems to automatically reconfigure if the package description file is newer than the configuration DB.)
I want to build an environment for tutorial programs for Haskell, as I want to try and learn the language. So I read about Cabal and already have it on my machine, because I updated pandoc sometimes. I followed some tutorials, which state that you should run:
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal build
To have the environment set up. However, if I try so, I receive the following message:
$ cabal sandbox init
Writing a default package environment file to
/home/xiaolong/development/Haskell/cabal.sandbox.config
Using an existing sandbox located at
/home/xiaolong/development/Haskell/.cabal-sandbox
(Output of ls command)
$ ls
cabal.sandbox.config
And then:
$ cabal install --only-dependencies
cabal: Error reading local package.
Couldn't find .cabal file in: .
Huh? Suddenly there needs to be a .cabal file? This is puzzling to me. What steps do I need to take to get an environment, in which I can simply install packages and then use that environment to run code of any tutorials I choose?
This is another tutorial suggesting the described workflow. Something is there I am missing.
(I am under the impression, that cabal sandboxes are comparable to python virtualenvs, being useful in the way, that one doesn't need to install packages system-wide, but can instead install them in a directory and then use that environment to run programs.)
You need to have a cabal file inside it which describes your project's name, package dependencies, license etc. A cabal file can be generated using cabal init which is followed by a series of question you have to answer.
Once the initial cabal configuration file is created, you can go inside the package directory and create sandbox inside it using the commands you have described above.
You may be also interested in Stack which is another alternate (better, if you would ask me :)) tool for developing Haskell projects.
I often have this issue when configuring a software on linux. When I install some library (for instance libsodium) by cloning the repository then doing the usual
./autoconf.sh
./configure
make
make install
I get everything install in /usr/local/ which is absolutely good for me.
Unfortunately, when I try to install something that depends on this library (for example libzmq, I get the issue
configure: error: Package requirements (libsodium) were not met:
No package 'libsodium' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables sodium_CFLAGS
and sodium_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
I guess the problem is because configure is looking on usr/ and not /usr/local. The ugly workaround is to install everything in usr/ instead of /usr/local. A more brutal approach would be to copy all what is installed in /usr/local into /usr/.
What is the correct solution when facing this kind of issues?
How should I adjust the PKG_CONFIG_PATH or the sodium_LIBS?
Set the PKG_CONFIG_PATH to /usr/local by means of your shell.
Some work with export, some with other means.
E. G.
export PKG_CONFIG_PATH=/usr/locall
run:
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
prior to ./autogen.sh && ./configure.
I have installed haskell into a custom location, which I have in my PATH:
C:\platforms\haskell\2014.2.0.0\bin
However, when I install a package globally, I get this:
Installing executable(s) in C:\Program Files\Haskell\bin
Warning: The directory C:\Program Files\Haskell\bin is not in the system
Where is it getting this path from, and how can I control where haskell will install packages globally? I would prefer they were installed in either the haskell install directory or my user profile somewhere.
Your cabal configuration has a block labeled install-dirs global which gives the directories to use for global installations. I'm not sure where this file sits on Windows, but in Linux, it is in ~/.cabal/config; so perhaps you can poke around in your profile's local settings directory for a directory named cabal or similar that contains a config file in it.
Adding to what MathematicalOrchid already mentioned, from the Cabal-Install wiki page:
You can edit the cabal configuration file to set defaults, for *nix
based systems this is:
~/.cabal/config
The config file on a Windows system is
%appdata%\cabal\config
Over here is the only reason I can find that packages I'm installing using cabal are not being found by GHC:
This happens when you install a package globally, and the previous packages were installed locally. Note that cabal-install install locally by default [...]
Presumably, "local installation" means putting packages in ~/.cabal/. First question: where are global installs?
I've been running cabal using sudo, so I guess that's a global install? The reason I've been doing this is that it complains about permissions when run without sudo, so this contradicts the statement "cabal-install install locally by default". Second question: how do I install locally and how do I install globally?
Trying to fix this mess, I've been randomly using sudo ghc-pkg unregister and randomly removing stuff from ~/.cabal/. Consequently my package tree is broken, probably locally and globally. Third question: How do I start again?
Edit: I'm running Ubuntu 10.10. I installed the Haskell Platform 2011.
Are you using Windows, OS X or some version of Linux? Are you using the Haskell Platform? Have you had a version of ghc or cabal before? For a Linux distribution, subtleties about your package manager may come in, of course. (Traces of an old ghc in particular, and an old ~/.ghc/ directory can be a source of trouble.)
Here are a few elementary thoughts of the type one goes through on #haskell with such problems. (My comprehension is not completely adequate, of course):
The chief question seems to be, Why you were being invited to do what should be local installs with sudo? A global install (cabal install pony --global) would of course require privileges if ghc and its libraries are in /usr/... or some other protected place, but otherwise sudo vs non-sudo is independent of the place of installation. What you do with cabal install pony --user (--user is the default, in theory) should not require superuser authority. (I have sometimes found on OS X that privileges are requested where the gcc needs to be called, but this has usually been due to curiosities about my setup.) But in any case sudo doesn't affect where cabal is putting them: the implicit --user and explicit --global, and more specific incantations for development, do that.
If you do ghc-pkg list, for example, it will divide the packages into the different places they are registered in according to two or more package.conf.d directories it is summarizing. On my laptop at the moment these are
/Users/applicative/.ghc/x86_64-darwin-7.0.3/package.conf.d/...
for the local things in ~/.cabal/lib/... and the protected
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/package.conf.d
for things that were installed globally with the Haskell Platform installer (this location involves some OS X peculiarities, ghc, ghci and so on are in the woods somewhere, but symlinked to /usr/bin). The conf files for different packages tell you exactly where the libraries were installed. So, for example about the sacred base library,
$ cat base-4.3.1.0-f5c465200a37a65ca26c5c6c600f6c76.conf
tells me:
import-dirs:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0
library-dirs:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0
In any case, where does ghc-pkg list say your cabal install-ed packages are going? In the ~/.cabal folder, look at the file config. If you haven't edited it, I think the commented and uncommented lines, if they state a preference, are stating the defaults for installation with --global and --user. In the ~.ghc/ directory check out the subdirectory myghcversion/package.conf.d and see if anything is there, which should be the same as what ghc-pkg tells you. (You might study the options for ghc-pkg in general, eg. ghc-pkg check and ghc-pkg recache, if you haven't. You may have installed something in some odd way.)
If you installed ghc and cabal and co. by installing the Haskell Platform with a binary installer or your package manager, which seems like a good idea, it is also a good idea, I think, to keep the Platform libraries as something sacred, and make sure you never install anything globally from Hackage; among other things this is likely to have you overwriting Platform libraries -- though this doesn't seem the difficulty here: it would be more obvious if it were.