commercialhaskell / commercialhaskell/stack

build: changing the package flags on command line has no impact on subsequent rebuilds

Open
#1,997 4 comments 0 reactions 0 assignees View on GitHub
component: docs (online)
Dominant language
Haskell
Stars
4.1k
Forks
850
Avg merge
10h 37m
Merged PRs (30d)
4

Description

I have the following conditional in my cabal file:

```
if flag(native)
ghc-options: -hide-package "unicode-transforms"
-package "unicode-transforms (Data.Text.NormalizeNative as Data.Text.Normalize)"

```

The flag works correctly (enabled/disabled) on a fresh clean build. But when I rebuild with a flag value which is different from the previous build then the project is not rebuilt with the changed flag. Here is the output after a changed flag:

```
cueball:/vol/hosts/cueball/workspace/projects/unicode-transforms$ stack build --flag unicode-transforms:native :bench
unicode-transforms-0.1.0.0: unregistering (flags changed from ["-f-native"] to ["-fnative"])
unicode-transforms-0.1.0.0: configure (lib + exe + bench)
Configuring unicode-transforms-0.1.0.0...
Warning: 'ghc-options: -hide-package' is never needed. Cabal hides all
packages.
unicode-transforms-0.1.0.0: build (lib + exe + bench)
Preprocessing library unicode-transforms-0.1.0.0...
In-place registering unicode-transforms-0.1.0.0...
Preprocessing executable 'ucd2haskell' for unicode-transforms-0.1.0.0...
Preprocessing benchmark 'bench' for unicode-transforms-0.1.0.0...
unicode-transforms-0.1.0.0: copy/register
Installing library in
/vol/hosts/cueball/workspace/projects/unicode-transforms/.stack-work/install/x86_64-linux/lts-5.8/7.10.3/lib/x86_64-linux-ghc-7.10.3/unicode-transforms-0.1.0.0-0Q21KoLEyBN0p0f5WJB5QO
Installing executable(s) in
/vol/hosts/cueball/workspace/projects/unicode-transforms/.stack-work/install/x86_64-linux/lts-5.8/7.10.3/bin
Registering unicode-transforms-0.1.0.0...
```

Also, note that it says `Warning: 'ghc-options: -hide-package' is never needed` but in my case it is needed because I am hiding the package and then exporting it with modules renamed. The renaming conflicts with an existing module with the same name in the same package if I do not hide it.

Is stack somehow thinking that none of the compilation flags have actually changed? And therefore there is no need to recompile?

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.