Paths_* modules cannot be found

[mrkkrp]

As you probably know there is a way to get version of package we're building by importing a special auto-generated module that is prefixed with Paths_. For example, I have a project called mmark-cli and so I would like to write the following:

module Main (main) where

import Paths_mmark_cli (version)

main :: IO ()
main = return ()

This succeeds with stack build but Flycheck reports an error:

Could not find module ‘Paths_mmark_cli’
Use -v to see a list of the files searched for.

Which is very unfortunate. Maybe this could be fixed somehow?

[mrkkrp]

The auto-generated module is located at .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0/build/mmark/autogen where mmark is the name of component (executable), mmark-cli is the name of package.

[mrkkrp]

It looks like the difference is in the presence of executable name:

Included by Flycheck: .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0/build/autogen
Needs to be included: .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.0.1.0/build/mmark/autogen
                                                                               ^^^^^

[mrkkrp]

I'm also getting:

Suspicious state from syntax checker haskell-stack-ghc: Flycheck checker haskell-stack-ghc returned non-zero exit code 1, but its output contained no errors: cc1: fatal error: cabal_macros.h: No such file or directory
compilation terminated.
`gcc' failed in phase `C pre-processor'. (Exit code: 1)

when I try to use CPP, namely the Cabal-generated definitions such as VERSION_my_package. I think the culprit may be the same.

[gahag]

I'm also having this. The same issue happens with stack ghci, it can't find the Paths_* module. I believe it is related to this issue in stack/cabal: commercialhaskell/stack#3791

[gahag]

I got rid of the issue, both in stack ghci and in flycheck, by changing the stack resolver from lts-10.3 to lts-9.21. It looks like the cause is a breaking change in the new cabal version.
I've also installed the flycheck-haskell package in emacs while attempting to solve the issue. Not sure if it's related.

[sergv]

Great, thanks for the investigation. I'll see what I can do.

On 20 January 2018 07:48:35 GMT+00:00, gahag ***@***.***> wrote: I got rid of the issue, both in stack ghci and in flycheck, by changing the stack resolver from lts-10.3 to lts-9.21. It looks like the cause is a breaking change in the new cabal version. I've also installed the flycheck-haskell package in emacs while attempting to solve the issue. Not sure if it's related. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #82 (comment)

Sergey

[sergv]

@mrkkrp @gahag I would apreciate if you could give my PR a spin and confirm that it works for you.

[sergv]

Should be fixed now. Please reopen if that's not the case.

[mrkkrp]

I'm experiencing this again. Now I'm on NixOS though. Anything I can do to help debug this?

[sergv]

Sorry for late reply - it seems that this project generates a bit more issues that its size may suggest. In order to be able to help you, please provide: 1. Reproducible example; 2. Output of `find <project--root> -name 'Paths_*'`; 3. Value of `flycheck-ghc-args` elisp variable in a buffer where errorneous behaviour is observed; 4. (optional) Output of the `<path to NixOS-blessed runghc> <path to flychec-haskell's get-cabal-configuration.hs> --cabal-file *.cabal` in the project's root dilectory.

…

On 11 April 2018 15:48:57 BST, Mark Karpov ***@***.***> wrote: I'm experiencing this again. Now I'm on NixOS though. Anything I can do to help debug this? -- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #82 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mrkkrp]

Huh, it looks like I can't reproduce it anymore. If I run into this again, I'll provide the info you requested!