Stack with ghcjs issues wrong warning about missing modules in cabal section "exposed-modules:".

[hansroland]

General summary/comments

In the cabal file I have list of exposed modules. Stack warns me that these modules should be added to the list of exposed modules. But they are already there!

OS Information

• OS: Linux Debian Jessie
• Stack version: Version 1.4.0, Git revision e714f1d (4640 commits) x86_64 hpack-0.17.0

Package to reproduce:

github.com/hansroland/ReflexScreenWidget
Use branch reflex-dom-0.4

Steps to reproduce

• Run command stack setup
• Run command stack build

Expected

No warning about missing modules in cabal exposed module section.

Actual

Stack produces the warning The following modules should be added to exposed-modules

Warning: The following modules should be added to exposed-modules or other-modules in /home/roland/Projekte/ReflexScreenWidget/ReflexScreenWidget.cabal:
    - In reflexScreenWidget component:
        GHCJS.Canvas.BlitByteString
        Reflex.Dom.AnimationFrame
        Reflex.Dom.Widget.Screen
        Reflex.Dom.Widget.Screen.Test

Missing modules in the cabal file are likely to cause undefined reference errors from the linker, along with other problems.

See log file https://gist.github.com/hansroland/b3a1eb969988da7513a3459cf79e5d63

The cabal file looks like:

library
  hs-source-dirs:      src
  ghc-options:         -Wall
  exposed-modules:     Reflex.Dom.Widget.Screen
                     , Reflex.Dom.Widget.Screen.Test
                     , Reflex.Dom.AnimationFrame
                     , GHCJS.Canvas.BlitByteString

stack.yaml file:

resolver: lts-6.25
compiler: ghcjs-0.2.0.9006025_ghc-7.10.3
compiler-check: match-exact

setup-info:
 ghcjs:
   source:
     ghcjs-0.2.0.9006025_ghc-7.10.3:
       url: http://ghcjs.tolysz.org/lts-6.25-9006025.tar.gz
       sha1: 3c87228579b55c05e227a7876682c2a7d4c9c007

flags: {}
extra-package-dbs: []
packages:
- '.'
- location:
    git:  https://github.com/ghcjs/ghcjs.git
    commit: 8c30beb939dadcb949b922856735080699d1d986
  subdirs:
  - lib/ghcjs-prim
  extra-dep: true
- location:
    git: https://github.com/ghcjs/ghcjs-base.git
    commit: dd7034ef8582ea8a175a71a988393a9d1ee86d6f
  extra-dep: true

- location:
    git: https://github.com/reflex-frp/reflex
    commit: 91299fce0bb2caddfba35af6608df57dd31e3690
  extra-dep: true

- location:
    git: https://github.com/reflex-frp/reflex-dom
    commit: 66b6d35773fcb337ab38ebce02c4b23baeae721e
  extra-dep: true


extra-deps:
- these-0.6.2.1
- prim-uniq-0.1.0.1
- ref-tf-0.4.0.1
- zenc-0.1.1

Stack version

Version 1.4.0, Git revision e714f1d (4640 commits) x86_64 hpack-0.17.0

Method of installation

curl -sSL https://get.haskellstack.org/ | sh

[hansroland]

@mgsloan: is the branch install-alex-and-happy-for-ghcjs-boot-3109 the correct branch to test? It has the right issue number #3109 but a confusing text about alex-and-happy.

[mgsloan]

Yeah, I got it mixed up with another ghcjs issue, that branch is actually for #3243 . Not sure yet what the bug is here, thanks for the report though!

[hansroland]

Thanks for your answer. So I will wait for a new notice of yours before I start testing.

[arvindd]

Additional information, but this in stack-version: Version 1.5.1, Git revision 600c1f0 x86_64 hpack-0.17.1, on Windows 10:

I noticed that this bug does not show itself if the executable is in a directory different from the library. As I see in the bug-report above, library's "hs-source-dirs" is mentioned as "src", and I think the executable's "hs-source-dirs" is also "src" in this case - which triggers this bug. In my case, I moved the executable to the directory "exe", and the problem is no more seen.

Hope this additional info helps in identifying the problem.

[mgsloan]

@arvindd Ah, yes, that makes sense. It is usually best practice to do that anyway. I have opened #3575 to track adding a warning in the case that there's a dependency between components but they also share hs-source-dirs. It's an anti-pattern that is almost always a mistake, it causes redundant compilation.

[hansroland]

Agreed! That's the problem. Closed in favour of #3575. Many thanks to both of you, @arvindd and @mgsloan !!