How to set cabal flag from shell.nix for stack project? - haskell

By default I build my project without nix, and executable is linked statically. But when building with nix, I want to link it dynamically instead. So I added a switch to myproj.cabal:
flag dynamic
description: Build only dynamic binaries
default: False
executable RunMe
ghc-options: -O2 -Wall
if !flag(dynamic)
ghc-options: -optl-static -static
Now I can build the project with
stack --nix --nix-packages=zlib install --flag myproj:dynamic
To avoid passing command line options every time, I created shell.nix:
{ghc}:
with (import <nixpkgs> {});
haskell.lib.buildStackProject {
inherit ghc;
name = "myproj";
buildInputs = [ zlib ];
}
Now, I don't know how to pass flag to cabal from nix file. Based on buildStackProject definition, I tried setting buildPhase, e.g.
haskell.lib.buildStackProject {
...
buildPhase = "stack build --flag=myproj:dynamic";
}
but it doesn't seem to change anything. How can I pass the flag to cabal from the nix file?

Unfortunately, the stack nix integration is rather backwards. It doesn't use nix to build your package (despite the very misleadingbuildStackPackage), just to create an environment with GHC and native dependencies. You have to use stack itself to build the project, and since stack will run cabal, it should still work with the flag. The stack nix integration will not generate a .nix file with the dependencies resolved by stack, so you can't build your project with nix-build and there's no point in entering nix-shell. You would have to use a tool like stack2nix or stackage2nix for that.
So to recap. The shell.nix above looks fine. Add this to your stack.yaml:
nix:
shell-file: shell.nix
And build the project with stack:
stack --nix --flag myproj:dynamic
That should build the project with the flag as usual, but use GHC and zlib from nix.

Related

How to build a project with an icon by `cabal build` or `stack build`

I want to build an executable with an icon. By googling it, I find the instruction here, but it only works by compiling a source file with ghc.
If I want to build a project with an executable by cabal build or stack build, how should I configure the .cabal or .yaml files such that cabal build or stack build can directly create an executable with an icon?
I've googled it for a while, but nothing useful.
I appreciate it if any tips are given.
According to #Willem Van Onsem's suggestion, the following is the solution:
for a stack project, add the following configure into the stack.yaml file
ghc-options:
"$targets": Icon.o
for a cabal project, add the following ghc-options into the .cabal file
ghc-options:
Icon.o

How do I supply a C library to stack on NixOS?

I have a stack-based project that depends on a couple C libraries. One of these C libraries, zlib, is available from a native NixOS package and I can put into the nix section of stack.yaml:
nix:
enable: true
packages:
- "zlib"
The other is not part of nixpkgs. The stack documentation suggests that the alternative to using the nix section in stack.yaml is to "write a shell.nix" without elaborating much.
So I wrote one, sticking to zlib as an example:
{ pkgs ? import <nixpkgs> { } }:
pkgs.mkShell {
buildInputs = [
pkgs.pkgconfig
pkgs.zlib
pkgs.stack
];
}
This gives me a working pkg-config for zlib:
[nix-shell:~/Work/PrivateStorage/PaymentServer]$ pkg-config --modversion zlib
1.2.11
However, it doesn't appear to make stack able to find the library:
[nix-shell:~/Work/PrivateStorage/PaymentServer]$ stack build
zlib-0.6.2: configure
Progress 1/7
-- While building package zlib-0.6.2 using:
/home/exarkun/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-2.4.0.1 configure --with-ghc=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/bin/ghc --with-ghc-pkg=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/pkgdb --libdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/lib --bindir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/bin --datadir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/share --libexecdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/libexec --sysconfdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/etc --docdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/doc/zlib-0.6.2 --htmldir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/doc/zlib-0.6.2 --haddockdir=/home/exarkun/.stack/snapshots/x86_64-linux-nix/lts-14.1/8.6.5/doc/zlib-0.6.2 --dependency=base=base-4.12.0.0 --dependency=bytestring=bytestring-0.10.8.2 --extra-include-dirs=/nix/store/a54skdf3xksiqvcvr75bjpdl1jx8dgbk-gmp-6.1.2-dev/include --extra-include-dirs=/nix/store/br7kq0kvbn73rhzl17js0w3pprphhzv1-git-2.19.2/include --extra-include-dirs=/nix/store/ghzg4kg0sjif58smj2lfm2bdvjwim85y-gcc-wrapper-7.4.0/include --extra-include-dirs=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/include --extra-lib-dirs=/nix/store/br7kq0kvbn73rhzl17js0w3pprphhzv1-git-2.19.2/lib --extra-lib-dirs=/nix/store/ghzg4kg0sjif58smj2lfm2bdvjwim85y-gcc-wrapper-7.4.0/lib --extra-lib-dirs=/nix/store/kggcrzpa5hd41b7v60wa7xjkgjs43xsl-gmp-6.1.2/lib --extra-lib-dirs=/nix/store/zfpm9bai9gj8vs09s2i2gkhvgsjkx13z-ghc-8.6.5/lib
Process exited with code: ExitFailure 1
Logs have been written to: /home/exarkun/Work/PrivateStorage/PaymentServer/.stack-work/logs/zlib-0.6.2.log
Configuring zlib-0.6.2...
Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5: Missing dependency on a foreign
library:
* Missing (or bad) header file: zlib.h
* Missing (or bad) C library: z
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
library file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
For zlib, there's no particular need to go this route, but as far as I can tell, I cannot put my non-nixpkgs package into the nix.packages list in stack.yaml.
How do I get stack to find these libraries?
Apparently a case of end-of-the-day documentation-reading-fail. This morning, it didn't take long to find the stack documentation that explains how to use a custom shell.nix. The stack docs do elaborate on how this works, including an example which shows it's not at all like the shell I thought was expected:
{ghc}:
with (import <nixpkgs> {});
haskell.lib.buildStackProject {
inherit ghc;
name = "myEnv";
buildInputs = [ glpk pcre ];
}
Adapting my shell to use buildStackProject instead of mkShell:
{ ghc }:
with (import <nixpkgs> { overlays = [ (import ./overlay.nix) ]; });
haskell.lib.buildStackProject {
inherit ghc;
name = "PrivacyPass";
# extra-library made available via the overlay.
# overlay probably not strictly necessary here, either.
buildInputs = [ zlib extra-library ];
}
and then pointing stack at it in stack.yaml:
nix:
enable: true
shell-file: "stack-shell.nix"
results in a successful build.

Stack won't resolve a 'hidden' dependency

I am working on my first major Haskell application, and want to add mockery to create disposable test WAI threads. Importing mockery and running stack test resulted in the compiler error:
Failed to load interface for ‘Test.Mockery.Directory’
It is a member of the hidden package ‘mockery-0.3.5’.
Perhaps you need to add ‘mockery’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
So, I added mockery to my cabal file under test dependencies. However, when I run stack build or stack test mockery is automatically removed from the cabal file.
I have also tried listing mockery-0.3.5 under extra-deps in the stack.yaml file. This unsurprisingly didn't work, since mockery is part of my lts, and extra deps is for packages outside of lts.
How can I get stack to recognize that mockery should be included as a dependency to to project?
Here is my stack.yaml:
flags: {}
ghc-options:
! '*': -Wall
packages:
- .
extra-deps: [
]
resolver: lts-9.5
I'm using stack version 1.5.1
I imagine this is a stupid build issue and look forward to confronting my obvious oversight.
In stack.yaml you declare the Stackage LTS version, a curated list of hackage dependencies that you want to depend on. You can also depend on local packages and packages in git that are not in Hackage. You may also change the versions of the packages in LTS as long as they respect the constraints of the other dependencies.
package.yaml is the build file. Any packages you want to import directly in your Haskell code must be declared in here as dependencies, even if they are explicitly declared in the stack.yaml.
Finally, when you see It is a member of the hidden package, that means that one of your dependencies is using that package, but it is not declared as a dependency in your build file.

stack --nix build complains about ghc version mismatch

When building threepenny-gui on NixOS with stack --nix build, I got error saying I have the wrong version of ghc. Then I tried stack --nix setup, which doesn't run because bash is on an unexpected path on NixOS (that's expected, since the stack documentation only mentions stack --nix build not setup). What am I missing?
FYI, to deal with the zlib issues I have also added a shell.nix and default.nix per https://github.com/commercialhaskell/stack/issues/2130
EDIT: was able to build with the method suggested by mkkeankylej from the above link, i.e. editing ~/.stack/config.yaml and add zlib to buildInputs in shell.nix But I'd still like to know if there's a way to do it w/o falling back to nix-shell? It sounds like stack --nix build should work as long as the nix-shell method does.
First of all, threepenny-gui seems to provide no stack.yaml, i.e. the project isn't configured to be built with stack. Thus, I wonder why you even bother using stack since that is not going to be any easier than building the project with cabal-install or even Nix directly. The easiest and fastest way is probably to configure the build by running:
$ nix-shell "<nixpkgs>" -A haskellPackages.threepenny-gui.env --run "cabal configure"
Afterwards, you can simply "cabal build" the project and work with it (inside or outside of a nix-shell) as you please; the compiler and all necessary build dependencies are provided by Nix.
If you don't want that, then you can use the normal cabal-install approach:
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal configure
$ cabal build
That build is probably going to require system libraries, like libz, so you must make sure that those are available. There's a million different ways to accomplish that, but the cleanest IMHO is the following:
$ zlibinc=$(nix-build --no-out-link "<nixpkgs>" -A zlib.dev)
$ zliblib=$(nix-build --no-out-link "<nixpkgs>" -A zlib.out)
$ cabal install --only-dependencies --extra-include-dirs=$zlibinc --extra-lib-dirs=$zliblib
Last but not least, it's not obvious to me why your stack build --nix command won't succeed, because that command will use Nix to install the proper version of GHC automatically. So if that doesn't work, then my best guess is that you're using an old version of stack where that feature doesn't work properly. I've tried that build using the stack binary that Nix provides, stack 1.3.2, and it can compile a current git checkout of threepenny-gui just fine:
$ git clone git://github.com/HeinrichApfelmus/threepenny-gui.git
Cloning into 'threepenny-gui'...
remote: Counting objects: 4102, done.
remote: Total 4102 (delta 0), reused 0 (delta 0), pack-reused 4101
Receiving objects: 100% (4102/4102), 1.88 MiB | 581.00 KiB/s, done.
Resolving deltas: 100% (2290/2290), done.
$ cd threepenny-gui
$ stack init
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- threepenny-gui.cabal
Selecting the best among 9 snapshots...
* Partially matches lts-7.16
websockets-snap not found
- threepenny-gui requires >=0.8 && <0.11
Using package flags:
- threepenny-gui: buildexamples = False, network-uri = True, rebug = False
* Matches nightly-2017-01-17
Selected resolver: nightly-2017-01-17
Initialising configuration using resolver: nightly-2017-01-17
Total number of user packages considered: 1
Writing configuration to file: stack.yaml
All done.
$ stack build --nix --nix-packages zlib
threepenny-gui-0.7.1.0: configure (lib)
Configuring threepenny-gui-0.7.1.0...
threepenny-gui-0.7.1.0: build (lib)
Preprocessing library threepenny-gui-0.7.1.0...
[...]
Registering threepenny-gui-0.7.1.0...
This works without any specially edited config files for nix-shell, nor does it require special customization of stack.

How to link to Haskell static runtime with cabal and stack without hard coding ghc version?

I have a project which exports a shared static library and I use the following part in my project.cabal file
executable libsxp.so
main-is: Somefile.hs
default-language: Haskell2010
ghc-options: -shared -dynamic -fPIC -lHSrts-ghc7.10.2
The version of GHC is controlled using Stack, so is there a way wherein I can either get and append the version to make -lHSrts-ghc{version} or is there some config for it? I tried setting
stack build --ghc-options='-O0 -lHSrts-ghc7.10.2'
but it doesn't seem to pick it.
Also to clarify, cabal install is called by Stack and not by me.
Does that cabal file work? If so, then it should be sufficient to do something like this:
executable libsxp.so
ghc-options: -shared -dynamic -fPIC
if impl (ghc >= 7.10.2 && < 7.10.3)
ghc-options: -lHSrts-ghc7.10.2
else if impl (ghc >= 7.10.3 && < 7.10.4)
ghc-options: -lHSrts-ghc7.10.3
else if ...
BTW, why does your executable end in .so? I've never seen that in an executable clause.
Are you sure you're using 7.10.2 and not 7.10.3? Try stack exec -- ghc --version
The general principle is described in this answer: https://stackoverflow.com/a/6034881/1663197
Using the configure style in Cabal, you can write a little configure
script that substitutes a variable for the output of the sdl-config
command. The values will then be replaced in a $foo.buildinfo.in file,
yielding a $foo.buildinfo file, that Cabal will include in the build
process.
First you need to switch your cabal build-type to Configure in project.cabal. Configure style is described in cabal users guide. For build type Configure the contents of Setup.hs must be:
import Distribution.Simple
main = defaultMainWithHooks autoconfUserHooks
In case of handling GHC runtime version you can have a variable #GHC_VERSION# corresponding to it in a project.buildinfo.in file:
ghc-options: -lHSrts-ghc#GHC_VERSION#
Finally you write a configure bash script that gets GHC version as mgsloan suggested and generates project.buildinfo file by substitution of #GHC_VERSION# varibale in project.buildinfo.in file:
GHC_VERSION=$(stack exec -- ghc-pkg field ghc version --simple-output)
sed 's,#GHC_VERSION#,'"$GHC_VERSION"',' project.buildinfo.in > project.buildinfo
This way when build is started it will first execute configure script, then read project.buildinfo file and merge with project.cabal.
Also it may be worth to populate extra-source-files with configure and
project.buildinfo.in; extra-tmp-files with project.buildinfo in project.cabal.
A more sophisticated solution may be inspired by this answer: https://stackoverflow.com/a/2940799/1663197

Resources