Global configuration for GHC build flags - haskell

Is there a place I can configure some default flags for GHC to use? I'd like, i.e., GHC to always assume I want the -fwarn-incomplete-patterns flag. This page gives a list of useful flags and indicates that some of them are on by default, but again, I'd like to change the defaults for my system.
I'm currently working on OS X, but I use Debian, Arch Linux, and Windows 8.1 at home, so a solution for any platform will help.

Apart from aliasing the shell command ghc to ghc -fwarn-incomplete-patterns, I don't think there's a way to do it globally or whether it would be advisable to do globally since it would probably generate an enormous amount of warnings when compiling external libraries with cabal. Probably best to do this one project at a time or just with GHCi:
There's a ghc-options section in any cabal file for a project.
library
...
ghc-options:
-fwarn-tabs
-fwarn-missing-local-sigs
-fwarn-incomplete-patterns
-fwarn-incomplete-uni-patterns
For global GHCi, you can add the following line to your ~/.ghc/ghci.conf
:set -fwarn-incomplete-uni-patterns

Add ghc-options: -fwarn-incomplete-patterns to the program-default-options section of your ~/.cabal/config:
[...]
program-default-options
...
ghc-options: -fwarn-incomplete-patterns
...
This only works with Cabalised projects (i.e. when you use cabal build/install/[...] instead of running ghc --make SomeFile.hs manually) and requires a fairly recent cabal-install (>= 1.18).

Just because this will be useful for people who come here:
On Gentoo, you can set options for all Cabal packages, (which is pretty much all of them) globally, in /etc/portage/make.conf, with the variable CABAL_EXTRA_BUILD_FLAGS. So in your case, that would be
CABAL_EXTRA_BUILD_FLAGS="--ghc-option=-fwarn-incomplete-patterns"
, and here is a more advanced example
CABAL_EXTRA_BUILD_FLAGS="--ghc-option=+RTS --ghc-option=-M1G --ghc-option=-RTS"
to limit memory usage to 1GB (and exit otherwise).
I think there’s a similar solution for Arch and Debian, but since OS X is a consumer OS, I don’t know.

Related

How can I run GHCi against a compiled package?

I should really know this by now, but I don't. I'm often working on a Cabal-based package and have just run a successful cabal build. Now I want to try some things out in GHCi. If I run cabal repl, then GHC recompiles the whole package into bytecode and runs it in the interpreter. Not what I want at all! If I were just running GHCi directly, I'd use something like -O -fobject-code, but that won't give me the package context. I just want "Give me a repl with the package as it's been compiled, compiling additional things only as necessary." How do I do it?
I don't know the right way, but I do know a workaround that can sometimes be useful. If the thing you care about is a library component, you can ask for a repl for an executable component.
I believe --repl-options -fobject-code kind of does what you want:
cabal repl --repl-options -fobject-code --repl-options -O --builddir dist-repl
This will give you incremental building of compiled code as you work in GHCi. Caveats:
dist-repl is an alternative directory for the -fobject-code build objects. As of cabal 3.6.2.0 at least, trying to reuse the regular output from cabal build leads to some unnecessary rebuilds and other strange behaviour, as reported at cabal issue #3565. That being so, it's better to compromise and use --builddir to keep a separate set of build objects. Note that cabal clean accepts the --builddir option just fine.
Setting the optimisation level explicitly is necessary, as otherwise the default -O0 from cabal repl will override your package setting.

Haskell profiling -prof

again...
I'm messing around with profiling in GHC after recently starting to learn Haskell. I'm trying to use profiling to see how different implementations of functions vary in performance, for example using list comprehension instead of map. I'm trying to compile with the -prof flag but im getting the following output:
david#david-LinuxMint ~/Desktop/Sandbox/Haskell/a $ ghc --make Filt -prof
Filt.hs:1:1:
Could not find module `Prelude'
Perhaps you haven't installed the profiling libraries for package `base'?
Use -v to see a list of the files searched for
The program compiles fine with the -prof flag omitted. Anybody have any ideas where im going wrong? I've tried to find something on SO/internet but my Google-Fu is failing me? Cheers.
This is for Linux, Debian in particular, but I believe the OP is using Mint which I think might be a Debian variant.
You probably got base from the OS packaging system (Debian: APT), so you'll also want to get the profiling version of base from that same system. On Debian the hackage package "foo" is in the Debian package "libghc-foo-dev"[1]. The profiling version of "libghc-blah-dev" is in the Debian package "libghc-blah-prof".
Now, base is a little special. Those packages exist, but are "virtual"; they are listed in relationships, but are actually installed by (one or more) other real packages. In Debian virtual libghc-base-dev is provided by real package ghc and virtual libghc-base-dev is provided by real package ghc-prof.
So, install ghc-prof (or the Mint equivalent) and you'll be good, or at least move on the the next error.
Eventually, you'll end up downloading and building packages directly from hackage. You'll have to change your cabal settings to build the profiling versions of those libraries.
[1] If another Haskell compiler gets (back) into Debian, the "ghc" in "libghc" will change to a string suitable for that compiler.

GHC options in cabal sandboxes

I'm doing cabal builds in various sandboxes with different combinations of GHC options. The flags I'm interested in are -O2, -O0, -threaded, and -feager-blackholing.
Firstly, for which of these flags does it make sense to apply to all packages in the sandbox, and which should only apply to the final executable package? For example, I believe -threaded only affects linking.
Secondly, how do I tell cabal to apply a flag to all packages? I tried creating a ghc-options: line in the sandbox cabal.config, but it complained. I tried creating a program-default-options stanza in cabal.config (like the one in ~/.cabal/config), but it complained about that too.

How can I specify which LLVM binaries GHC should use?

I have successfully built PortFusion with the brand new 64-bit GHC 7.6.1 Release Candidate 1 for Windows.
Using freshly downloaded native 64-bit mingw binaries from http://www.drangon.org/mingw, the network package was as easy to install (after a bunch of non-relevant small fixes) as a simple
CC=mingw64/bin/gcc cabal install
There is also an LLVM toolchain package on the same website.
Now I wonder how I could tell GHC to use specific LLVM binaries during compilation.
Would it be something as simple and similar to above as:
#v??v
LLVM=????????? ghc -W -O2 -fllvm -optlo-O3 --make src/Main.hs
LLVM=????????? cabal install PortFusion -f llvm #¹
#^??^
¹ relevant line in PortFusion.cabal defining the llvm flag
or completely different?
For the record, the answer to the question in the title is
ghc -pgmlo opt_cmd -pgmlc llc_cmd -fllvm ...
opt_cmd and llc_cmd can be either command names (that will be looked up in PATH) or full pathnames.
You may be able to get GHC to use certain binaries by altering where they are defined in the PATH environment variable. Earlier takes precedence. Presumably, System PATH is also higher precedence than User PATH.

Control.Parallel compile issue in Haskell

The compiler is complaining each time on different example applications of parallel Haskell; with this message:
Could not find module `Control.Parallel.Strategies'
The ghc compiler command:
ghc -threaded -i/sudo/dir/par-modules/3 -cpp -DEVAL_STRATEGIES -eventlog --make parFib.hs
Same with simpler
ghc -O2 --make -threaded parFib.hs
What detail am I overlooking? Am I missing some PATH variable.
Imports can look like this:
module Main where
import System
# if defined(EVAL_STRATEGIES)
import Control.Parallel
import Control.Parallel.Strategies
#endif
Cheers
You must install the parallel package from Hackage. In most sane setups, this should be as simple as typing
cabal install parallel # note: not sudo cabal install parallel!
at your command prompt.
I'm adding a new answer (instead of a comment) for visibility reasons.
After trying Daniel's answer, I still wasn't able to do import Control.Parallel, neither from ghci, nor with the compiler. The install command returned a warning message like this:
➜ ~ cabal install parallel
Resolving dependencies...
Up to date
Warning: You asked to install executables, but there are no executables in
target: parallel. Perhaps you want to use --lib to install libraries instead.
What ultimately resolved the issue was:
cabal install --lib parallel
Like Daniel said, you'll need the parallel package. However if you'd prefer to use your system's package manager (which some people think you should), you can.
Note that, at least in the Fedora repos, you'll need ghc-parallel-devel, not just ghc-parallel to build.
#yum install ghc-parallel-devel

Resources