commercialhaskell / commercialhaskell/stack

stack nix integration does not rebuild packages when STACK_IN_NIX_EXTRA_ARGS changes

Open
#2,802 11 comments 1 reaction 0 assignees View on GitHub
component: nix
Dominant language
Haskell
Stars
4.1k
Forks
850
Avg merge
10h 37m
Merged PRs (30d)
4

Description

I have a setup whereby I have a nix shell with all the C/C++ libraries that I need, and then a Haskell project using them. I'm using `stack --nix` to build the Haskell project.

Now let's say my main Haskell package in the project is A, and it depends on some other Haskell packages such as B, and it also depends on some C libraries that it picks up from nix. Package A has some C files that depend on the C libraries provided by the nix environment.

The way this all works is that the paths to the C libraries are picked up by stack in `STACK_IN_NIX_EXTRA_ARGS`. So the first time I build A, both A and B are going to build with the include dirs and library dirs dictated by `STACK_IN_NIX_EXTRA_ARGS`. So far so good. Note that as a consequence of this both A and B are going to have these include and library dirs in their info, as can be verified with `stack --nix exec -- ghc-pkg describe A` and `stack --nix exec -- ghc-pkg describe B`.

However, say that I upgrade one of the C libraries in the nix environment, thus changing its hash. I then upgrade Haskell package A to use some facility of this new library. What should happen is that _all_ the Haskell packages that were built with the old version of the library are rebuilt, but currently that does not happen -- only A is rebuilt.

The immediate problem that this behavior causes is that when GHC invokes the C compiler to compile the C files in Haskell project A, it provides both the new include dirs (from the latest invocation of ghc by stack) and the old include dirs (remembered by GHC as include dirs in the package info of B). By chance the include dirs in B happen to "win", and thus A cannot see the header files for the new version of the C library.

Besides the symptom described, it seems clear to me that if a C library is change all the Haskell packages that were built with it should be rebuilt too.

### Stack version

```
$ stack --version
Version 1.2.0, Git revision 241cd07d576d9c0c0e712e83d947e3dd64541c42 (4054 commits) x86_64 hpack-0.14.0
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.