I try to setup a stack based Haskell IDE with vscode and start with a small project created with stack init and then added a second module in src and added some dependencies in package.yaml. It builds ok but when I start stack ghci I have warnings:
Warning: Multiple files use the same module name:
* Paths_primo found at the following paths
* /home/frank/Workspace11/primo/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/autogen/Paths_primo.hs (primo:lib)
* /home/frank/Workspace11/primo/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/primo-exe/autogen/Paths_primo.hs (primo:exe:primo-exe)
* * * * * * * *
GHCi, version 8.10.4: https://www.haskell.org/ghc/ :? for help
[1 of 3] Compiling Lib ( /home/frank/Workspace11/primo/src/Lib.hs, interpreted )
[2 of 3] Compiling YamlRead ( /home/frank/Workspace11/primo/src/YamlRead.hs, interpreted )
[3 of 3] Compiling Main ( /home/frank/Workspace11/primo/app/Main.hs, interpreted )
Ok, three modules loaded.
There seems to be a confusion with autogen and with Paths_primo (primo is the name of the package). What am I doing wrong?
General question: what is the correct way to clean a stack project to "start over" after some experimentation? Is is correct to delete the cabal file and the stack-work directory. Waht is with stack.yaml and 'stack.yaml.lock`?
This appears to be a harmless warning reported at Stack issue #5439, whose underlying cause is hpack issue #303. A workaround to get rid of the warning is disabling the generation of the Paths_ module for your primo-exe executable, by adding the following to its section in package.yaml:
when:
- condition: false
other-modules: Paths_primo
Related
when I type stack run I get no error message but when I type stack ghci I get this error about multiple files use the same name , how I can solve it ?
(base) wejden#wejdenaydi:~/wejden$ stack ghci
Using main module: 1. Package `wejden' component wejden:exe:wejden-exe with main-is file: /home/wejden/wejden/app/Main.hs
Building all executables for `wejden' once. After a successful build of all of them, only specified executables will be rebuilt.
wejden> configure (lib + exe)
Configuring wejden-0.1.0.0...
wejden> initial-build-steps (lib + exe)
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: wejden
* * * * * * * *
Warning: Multiple files use the same module name:
* Paths_wejden found at the following paths
* /home/wejden/wejden/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/autogen/Paths_wejden.hs (wejden:lib)
* /home/wejden/wejden/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/wejden-exe/autogen/Paths_wejden.hs (wejden:exe:wejden-exe)
* * * * * * * *
GHCi, version 8.10.4: https://www.haskell.org/ghc/ :? for help
[1 of 3] Compiling Lib ( /home/wejden/wejden/src/Lib.hs, interpreted )
[2 of 3] Compiling Main ( /home/wejden/wejden/app/Main.hs, interpreted )
[3 of 3] Compiling Paths_wejden ( /home/wejden/wejden/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/build/autogen/Paths_wejden.hs, interpreted )
Ok, three modules loaded.
Loaded GHCi configuration from /tmp/haskell-stack-ghci/f99925e2/ghci-script
*Main Lib Paths_wejden>
For those who, like me, need very specific instructions, here it goes:
executables:
mypkgname-exe:
main: Main.hs
source-dirs: app
ghc-options:
- -threaded
- -rtsopts
- -with-rtsopts=-N
dependencies:
- stocks
when:
- condition: false
other-modules: Paths_mypkgname
where mypkgname needs to be replaced with your package name. I'm posting this because on my first attempt I had put the when clause in the wrong place.
This is a known issue with hpack: https://github.com/commercialhaskell/stack/issues/5439
In short, add this in your package.yaml, to your executable(s) or your library:
when:
- condition: false
other-modules: Paths_wejden # your package name here
I have a small haskell program which builds and executes with stack ok. When I start it with stack ghci I have an error message which I do not understand and cannot proceed.
GHCi, version 8.10.4: https://www.haskell.org/ghc/ :? for help
[1 of 3] Compiling Lib ( /home/frank/Workspace11/primo/src/Lib.hs, interpreted )
[2 of 3] Compiling YamlRead ( /home/frank/Workspace11/primo/src/YamlRead.hs, interpreted )
[3 of 3] Compiling Main ( /home/frank/Workspace11/primo/app/Main.hs, interpreted )
Ok, three modules loaded.
Loaded GHCi configuration from /home/frank/Workspace11/primo/.ghci
<no location info>: error:
module ‘main:Main’ is defined in multiple files: /home/frank/Workspace11/primo/app/Main.hs
/home/frank/Workspace11/primo/app/Main.hs
I do not see why the same Main is listed twice in the exact same file.
I had a somewhat similar warning message about Paths_primo which is a known bug ( Stack issue #5439 ) and I fixed following the advice see.
What is the cure against this error? I have not used stack much - am I doing something wrong?
This looks like a sign that Main.hs or Main is inadvertently listed multiple times in your Stack package.yaml, in such a way that ghc is invoked with multiple occurrences of it.
This error is possible to reproduce easily with GHC alone, for example:
> echo 'main = putStrLn "hello"' > Hello.hs
> ghc Hello Hello.hs
<no location info>: error:
module ‘main:Main’ is defined in multiple files: Hello.hs Hello.hs
I would run Stack with --verbose and see how GHCi is being invoked, and double-check the package.yaml and generated Cabal file. (If you edit your question to include that, we may be able to offer more specific help with it.)
I can think of several possible reasons for this, such as literally listing Main or Main.hs multiple times (e.g. in exposed-modules, other-modules, main-is); or an interaction like a missing option value in the ghc-options field causing subsequent flags to be misinterpreted.
Main.hs can be listed multiple times in GHCi invocation when it is present in multiple components. Typical way when this happens is:
You create a project with stack new which contains single src/Main.hs file, so package.yaml has an executable entry and no library entry.
Then you add a library and use source-dir: src. Now Main.hs is listed in two components: myapp-lib and myapp-lib-exe. Assuming you package name is myapp.
To solve the problem you should move Main.hs to app dir and update executables:source-dirs to app in package.yaml.
So the problem may happen when Main.hs is listed in multiple components in package.yaml, for example in executables and library.
I'm looking at the following module: https://hackage.haskell.org/package/boxes-0.1.4/docs/src/Text-PrettyPrint-Boxes.html
Which has contents of:
module Text.PrettyPrint.Boxes
( -- * Constructing boxes
#ifdef TESTING
Box(Box, content)
#else
Box
#endif
How can I enable / define the TESTING value - for development purposes? Ideally I'd like to have this built / enabled within a GHCi session.
I have to correct myself - the comment I gave is totally and utterly wrong.
> git clone git://github.com/treeowl/boxes.git
> cd boxes
> stack init
> stack ghci --ghc-options=-DTESTING
split-0.2.3.2: using precompiled package
boxes-0.1.4: configure (lib)
Configuring boxes-0.1.4...
boxes-0.1.4: initial-build-steps (lib)
Completed 2 action(s).
Configuring GHCi with the following packages: boxes
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from ...
[1 of 1] Compiling Text.PrettyPrint.Boxes ( .../boxes/Text/PrettyPrint/Boxes.hs, interpreted )
Ok, modules loaded: Text.PrettyPrint.Boxes.
Loaded GHCi configuration from /tmp/ghci28386/ghci-script
*Text.PrettyPrint.Boxes Text.PrettyPrint.Boxes> :t content
content :: Box -> Content
just works fine.
I have a project which pulls in two local packages. My stack.yaml has:
packages:
- '.'
- '../creatur-wains'
- '../creatur-wains-test-utils'
Both creatur-wains and creatur-wains-test-utils define a module called ALife.Creatur.Wain.TestUtils, but in creatur-wains it's only part of the test code, not part of the library. This wasn't a problem when I was using ghci. I could load both packages, and only the version of TestUtils from creatur-wains-test-utils was visible.
However, Stack also seems to pull in the test modules from creatur-wains, so I get the following error:
$ stack repl
The following GHC options are incompatible with GHCi and have not been passed to it: -Werror -threaded
Configuring GHCi with the following packages: creatur-dvector-wains, creatur-wains-test-utils, creatur-wains
* * * * * * * *
The following modules are present in multiple packages:
* ALife.Creatur.Wain.TestUtils (in creatur-wains, creatur-wains-test-utils)
* * * * * * * *
Not attempting to start ghci due to these duplicate modules.
Use --no-load to try to start it anyway, without loading any modules (but these are still likely to cause errors)
I can work around this using --no-load, and adding the packages one by one, but that's a bit tedious. Is this desireable behaviour for stack repl, or is it a bug?
From the stack ghci docs (https://docs.haskellstack.org/en/stable/ghci/):
Similarly to stack build, the default is to load up ghci with all libraries and executables in the project.
So, to load just one package you need to do stack ghci creatur-wains.
I created a new project and, as you can see, it even downloaded a brand new build plan for lts-7.4, which as you can see uses ghc-8.0.1.
But when running stack ghci, it built the project with GHC 7.10, and dropped me in a 7.10 ghci shell.
dario#curie /tmp> stack new foo
Downloading template "new-template" to create project "foo" in foo/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- foo/foo.cabal
Selecting the best among 9 snapshots...
Downloaded lts-7.4 build plan.
* Matches lts-7.4
Selected resolver: lts-7.4
Initialising configuration using resolver: lts-7.4
Total number of user packages considered: 1
Writing configuration to file: foo/stack.yaml
All done.
dario#curie /tmp> cd foo
dario#curie /t/foo> stack ghci
foo-0.1.0.0: configure
Configuring foo-0.1.0.0...
foo-0.1.0.0: build
Preprocessing library foo-0.1.0.0...
[1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Lib.o )
In-place registering foo-0.1.0.0...
Preprocessing executable 'foo-exe' for foo-0.1.0.0...
[1 of 1] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe ...
foo-0.1.0.0: copy/register
Installing library in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/lib/x86_64-linux-ghc-7.10.3/foo-0.1.0.0-6bylsnNRJPuHxByS3dKqs5
Installing executable(s) in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/bin
Registering foo-0.1.0.0...
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `foo' component exe:foo-exe with main-is file: /tmp/foo/app/Main.hs
Configuring GHCi with the following packages: foo
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Lib ( /tmp/foo/src/Lib.hs, interpreted )
Ok, modules loaded: Lib.
[2 of 2] Compiling Main ( /tmp/foo/app/Main.hs, interpreted )
Ok, modules loaded: Lib, Main.
>
I always relied on the assumption that for every stackage snapshot, stack would use only one version of GHC, am I wrong?
I don't have system-ghc: true in my config, and the faq doesn't mention many other alternatives
This is the output of stack path:
dario#curie /t/foo> stack path
stack-root: /home/dario/.stack
project-root: /tmp/foo
config-location: /tmp/foo/stack.yaml
bin-path: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/bin:/home/dario/.stack/programs/x86_64-linux/ghc-8.0.1/bin:/home/dario/Applications/bin:/home/dario/.rbenv/shims:/home/dario/.cabal/bin:/home/dario/.nix-profile/bin:/home/dario/.nix-profile/sbin:/home/dario/.sdkman/candidates/grails/current/bi n:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/dario/.local/bin:/home/dario/.nix-profile/bin
programs: /home/dario/.stack/programs/x86_64-linux
compiler-exe: /usr/bin/ghc
compiler-bin: /usr/bin
local-bin: /home/dario/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb
local-pkg-db: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb
global-pkg-db: /var/lib/ghc/package.conf.d
ghc-package-path: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb:/home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb:/var/lib/ghc/package.conf.d
snapshot-install-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3
local-install-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3
snapshot-doc-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/doc
local-doc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/doc
dist-dir: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0
local-hpc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/hpc
local-bin-path: /home/dario/.local/bin
ghc-paths: /home/dario/.stack/programs/x86_64-linux
dario#curie /t/foo> echo $PATH
/home/dario/Applications/bin /home/dario/.rbenv/shims /home/dario/.cabal/bin /home/dario/.nix-profile/bin /home/dario/.nix-profile/sbin /home/dario/.sdkman/candidates/grails/current/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /usr/lib/jvm/java-8-oracle/bin /usr/lib/jvm/java-8-oracle/db/bin /usr/lib/jvm/java-8-oracle/jre/bin /home/dario/.local/bin /home/dario/.nix-profile/bin
I rely on the lts determining the version of ghc in use also for CI, so it's a bit worrying if my assumption doesn't hold (anymore?)
(I'm running stack Version 1.2.0 x86_64 hpack-0.14.0)
This is the output of stack setup
dario#curie /t/foo> stack setup
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
I realized that this was due to the faulty way in which I "worked around" this issue:
https://github.com/commercialhaskell/stack/issues/2712
I might open it as another bug report, but it's definitely less important/interesting than fixing #2712