Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack not detecting changes for incremental builds #481

Closed
timbod7 opened this issue Jul 1, 2015 · 5 comments
Closed

Stack not detecting changes for incremental builds #481

timbod7 opened this issue Jul 1, 2015 · 5 comments
Assignees
Milestone

Comments

@timbod7
Copy link

timbod7 commented Jul 1, 2015

Trying out stack for the first time.

It builds my application correctly, but only rebuilds when Main.hs is touched, not the other files.

$ stack build
$ touch Weafe/Types.hs 
$ stack build
$ touch Weafe/Main.hs 
$ stack build
weafe-0.1.0.0: build
Building weafe-0.1.0.0...
Preprocessing executable 'weafe' for weafe-0.1.0.0...
[5 of 7] Compiling Weafe.Types      ( Weafe/Types.hs, .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/weafe/weafe-tmp/Weafe/Types.o )
[7 of 7] Compiling Main             ( Weafe/Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/weafe/weafe-tmp/Main.o )
Linking .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/weafe/weafe ...
weafe-0.1.0.0: install
Installing executable(s) in
/Users/timd/repos/weafe-hs/.stack-work/install/x86_64-osx/lts-2.15/7.8.4/bin
$ 

The cabal file only reference Main.hs:

...
executable weafe
  main-is:             Weafe/Main.hs
...
@snoyberg
Copy link
Contributor

snoyberg commented Jul 2, 2015

This is a known limitation. Currently you need to mention additional
modules in other-modules. There's an open issue about tracking this
information properly, but I can't look it up right now due to no internet
access.

On Wed, Jul 1, 2015, 11:22 PM Tim Docker notifications@github.com wrote:

Trying out stack for the first time.

It builds my application correctly, but only rebuilds when Main.hs is
touched, not the other files.

$ stack build
$ touch Weafe/Types.hs
$ stack build
$ touch Weafe/Main.hs
$ stack build
weafe-0.1.0.0: build
Building weafe-0.1.0.0...
Preprocessing executable 'weafe' for weafe-0.1.0.0...
[5 of 7] Compiling Weafe.Types ( Weafe/Types.hs, .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/weafe/weafe-tmp/Weafe/Types.o )
[7 of 7] Compiling Main ( Weafe/Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/weafe/weafe-tmp/Main.o )
Linking .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/weafe/weafe ...
weafe-0.1.0.0: install
Installing executable(s) in
/Users/timd/repos/weafe-hs/.stack-work/install/x86_64-osx/lts-2.15/7.8.4/bin
$

The cabal file only reference Main.hs:

...
executable weafe
main-is: Weafe/Main.hs
...


Reply to this email directly or view it on GitHub
#481.

@snoyberg
Copy link
Contributor

snoyberg commented Jul 2, 2015

The other issue is #105, which @DanBurton is working on. I'll assign this issue to him as well, though the resolution should be the same for both.

@ecognium
Copy link
Contributor

ecognium commented Aug 7, 2015

It looks like stack 0.1.2.0 on Mac OSX has an issue with picking up changes made to test-suites. This issue does not exist with Version 0.1.1.0.

My .cabal file looks like:

test-suite api-test
  type:                exitcode-stdio-1.0
  hs-source-dirs:      tests
  main-is:             Spec.hs
  build-depends:       aeson >= 0.8 && < 0.10
                                .... 

I have modules that are called from Spec.hs. When the contents of the module changes, stack does not rebuild on stack test. Even touch Spec.hs does not force it to rebuild. However, adding a single useless byte to Spec.hs (or any actual code change) triggers a recompilation of both the module and Spec.hs.

I also tried adding other-modules: to the test-suite but I am not sure if it is actually a valid cabal syntax. Regardless it did not make a difference.

I have gone back to the previous version and that does not have this issue.

@borsboom
Copy link
Contributor

borsboom commented Aug 8, 2015

Would anyone seeing these problems mind trying out the code in PR #734? If that fixes it, then this is indeed a duplicate of #32.

@borsboom
Copy link
Contributor

borsboom commented Aug 9, 2015

Closing this for now on the assumption that #734 (now on master) fixed it. Please re-open if not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants