stack build does not rebuild executable without other-modules

[spl]

This may be a known issue. If so, I think it could be documented better. I could not find a clear answer in the issue archive to match this, so, at the very least, this issue might help others who encounter the problem.

Steps to reproduce:

1. Create a .cabal for an executable.
   • Include the hs-source-dirs field mentioning the source directories with the modules.
   • Do not include the other-modules field with the modules listed.
2. Create a stack from that .cabal.
3. stack build the first time.
4. Change a module in the package.
5. stack build to rebuild.

Expected:

The project rebuilds.

Actual:

The project does not rebuild.

Discussion:

I couldn't figure out why my project wasn't rebuilding. Then, I found that if I include other-modules with a module M and update M, the project would rebuild. If I then change N, a module not listed in other-modules, the project would not rebuild.

Related:

These issues seem to be related:

• Detect when a module is compiled but not listed in the cabal file Detect when a module is compiled but not listed in the cabal file #32
• Respect TemplateHaskell addDependentFile dependency changes Respect TemplateHaskell addDependentFile dependency changes #105
• Stack not detecting changes for incremental builds Stack not detecting changes for incremental builds #481
• Stack not rebuilding Stack not rebuilding #573
• stack test not detecting changes to the test suite stack test not detecting changes to the test suite #556

From my cursory reading, it seems like this issue was supposed to be fixed in:

• Detect unlisted modules and TH dependent files Detect unlisted modules and TH dependent files (#32,#105) #734

There seems to be a currently undocumented --force-dirty flag added in 09a9fa4 to deal with this kind of issue.

I believe I did see a warning for unlisted modules (added in 31712d3?), but I wasn't sure what the warning was for. I wasn't even sure what an “unlisted module” was. Why would unlisted modules be a problem? If this issue is the reason for that warning, then the warning text could be improved.

Questions:

If this is a known issue with no fix currently planned, could it be documented better or handled by stack?

• One option would be to mention it somewhere in the guide. The “Build command” section would be a good place to start with.
• Another option would be to automate the check with stack and report it.

[mgsloan]

Hey, thanks for the details! I tried

name:                issue2341
version:             0.1.0.0
cabal-version:       >=1.10

executable issue2341-exe
  main-is:             Main.hs
  build-depends:       base
  default-language:    Haskell2010

With Main.hs

import Lib

main = putStrLn "hi"

and Lib.hs

module Lib where

Changes to Lib cause rebuild despite not being listed in other-modules.

One option would be to mention it somewhere in the guide. The “Build command” section would be a good place to start with.

I've documented some more of the flags there, good idea!

[spl]

@mgsloan: Thanks for trying to reproduce it. I take it from your response that this is not a known problem?

Two things to add:

• I don't see hs-source-dirs in your .cabal. I had hs-source-dirs: src with all modules under the src/ directory.
• This is a ghcjs project. I'm not sure if that makes a difference.

[spl]

Also, thanks for improving the documentation. 💯

[mgsloan]

This is indeed related to using GHCJS. With GHC I get:

However, GHCJS doesn't seem to output these ddump-hi files, and so we can't keep track of dirtiness.

[mgsloan]

@spl I believe I've resolved the issue. Now, all local ghcjs packages will be assumed to be dirty, because we can't be sure.

Please re-open and comment if the git version of stack doesn't solve the problem for you.

[spl]

Nicely done. I think that's a reasonable solution. Thanks!

[mgsloan]

Welcome, thanks for bringing up the issue!

[mgsloan]

@spl I have figured out why ddump-hi files aren't being produced - see #2714 . I've fixed that issue, and reverted the special case of assuming ghcjs local packages are dirty.