I am attempting to build a project which uses Euterpea.
Running stack build I get the following error, suggesting that I need to add Euterpea to the build-depends section of my .cabal file.
$ sb
composition-0.1.0.0: build (lib + exe)
Preprocessing library composition-0.1.0.0...
[2 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/Lib.o )
/home/matthew/backup/composition/composition/src/Lib.hs:5:1: error:
Failed to load interface for ‘Euterpea’
It is a member of the hidden package ‘Euterpea-2.0.4’.
Perhaps you need to add ‘Euterpea’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
-- While building package composition-0.1.0.0 using:
/home/matthew/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0 build lib:composition exe:composition-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
I add Euterpea there, and the library section of my .cabal file then is the following.
library
hs-source-dirs:
src
build-depends: base >= 4.7 && < 5
, Euterpea
exposed-modules:
Lib
other-modules:
Paths_composition
default-language: Haskell2010
However, when I then run stack build again, it gives the same error -- and changes my .cabal file back to what it was originally, with the library section then looking like
library
hs-source-dirs:
src
build-depends:
base >= 4.7 && < 5
exposed-modules:
Lib
other-modules:
Paths_composition
default-language: Haskell2010
Why is stack build altering my cabal file? I have never seen that occurring before.
Side note:
Not sure if it is related, but the .cabal file's format appears to be different than it normally does. Here as with previous projects I auto-initialized by running stack new <project-name>. I don't know what I might have done different from previous projects to cause this unexpected behavior of stack build.
Make sure package.yaml exists in the root of your project directory.
package.yaml is a new file format to improve the syntax of cabal, converted by hpack.
Stack supports hpack as strongly as the stack build command automatically converts package.yaml into a cabal file with hpack command.
So, delete package.yaml or edit package.yaml to add Euterpea package.
Editing it would not be so difficult as its format is YAML.
I want to add to the YAMAMOTO Yuji's answer. The solution is absolutely right. But I just wanted to add few things, it is not hard to edit the package.yaml.
Step 1 : The trickiest part is finding the correct package name.
Use Hoogle or Stackage to find the package where the module
resides. Read more about how to find package name in this post.
Step 2 : Now you have to open the package.yaml file and add the package name. In your case add 'Euterpea' package in the list of dependencies.
dependencies:
...
- your-package-name
Please note that Euterpea package has to be added in a different way. Please read this
post for better understanding.
Step 3 : Open project-name.cabal in project root and add required package name under build-depends:
library
hs-source-dirs:
src
build-depends:
base >= 4.7 && < 5
, your-package-name
exposed-modules:
Lib
Step 4 :Issue stack build to download and build dependencies
(or stack ghci if you plan to use it in the REPL)
Hope this works! Happy coding! :)
Related
I'm trying to build a Haskell project using Cabal. I have a file src/Main.hs which contains the module Main and a function main. That file runs the web interface of my app. And I have another file, src/CLI.hs which contains the module CLI and a function main. I can run it just fine with runhaskell CLI ..., but I can't seem to compile it using cabal.
The thing is, even if I specify CLI.hs as the main file (main-is: CLI.hs), it still compiles the project with the main from src/Main.hs, thereby giving me the web app instead of the CLI.
I want to be able to compile two executables, one which is the web app, and one which is the CLI, specifying the entry points of each as main in CLI.hs and main in Main.hs, respectively.
Here's the segment of the .cabal file I'm using at the moment:
executable color-word-analyzer-cli
main-is: CLI.hs
other-modules: AnnotateColors
, CategorizeColor
, ColorMaps
, FindColors
, PlotColors
, Types
, Main
build-depends: base
, lucid
...
, wai-middleware-static
hs-source-dirs: src/
default-language: Haskell2010
executable color-word-analyzer-web
main-is: Main.hs
other-modules: AnnotateColors
, CategorizeColor
, ColorMaps
, FindColors
, PlotColors
, Types
, CLI
build-depends: base
, lucid
...
, wai-middleware-static
hs-source-dirs: src/
default-language: Haskell2010
Which throws the error (among others):
Building executable 'color-word-analyzer-cli' for color-word-analyzer-0.1.0.0..
Warning: Enabling workaround for Main module 'Main' listed in 'other-modules'
illegally!
<no location info>: warning: [-Wmissing-home-modules]
These modules are needed for compilation but not listed in your .cabal file's other-modules:
Main
which is funny, since Main is clearly listed there in other-modules.
I'm using cabal version 3.0.0.0, and ghc version 8.8.2.
The fully explicit form of a compilation unit is <package>:<category>:<ident> where in the case the packages is color-word-analyzer, category is exe and ident is the executables. So for your case you can call:
cabal build color-word-analyzer:exe:color-word-analyzer-cli color-word-analyzer:exe:color-word-analyzer-web
Now you don't actually need to specify all of that. When the executable is unique the fact that it is an executable (and not, say, a test from some other package or another package name itself) and the fact that it is from color-word-analyzer is clear in this context. You can therefore call:
cabal build color-word-analyzer-cli color-word-analyzer-web
EDIT: because your link didn't have a stanza for -web I used one of my own creation which didn't include the CLI module. Notice your CLI file is module Main so that explains the error you see - you can't include a module Main as a library module.
I am trying to add dependency of gtk2hs-buildtool to my Haskell project but following error while building stack.
In the dependencies for TicTacToe-0.1.0.0:
gtk2hs-buildtools needed, but the stack configuration has no specified version (latest matching
version is 0.13.5.4)
needed since TicTacToe is a build target.
TicTacToe.cabal file:
library
exposed-modules:
TicTacToeEngine
other-modules:
Paths_TicTacToe
hs-source-dirs:
src
build-depends:
base >=4.7 && <5,
gtk2hs-buildtools
default-language: Haskell2010
If you are using stack tool you shouldn't touch the <packagename>.cabal file. stack is in charge to generate it from package.yaml. Despite of the fact that is a common practise to modify the <packagename>.cabal, development workflow will be easier if you don't.
The files you are interested in (and the ones that stack tool uses) are the stack.yaml and package.yaml.
In stack.yaml you should see an entry called resolver: lts-XX.XX. That means that your dependencies version are managed such that they match those in the given lts (a.k.a. snapshot). You can go to https://www.stackage.org/, click on your lts version and search for the gtk2hs-buildtools package to get the right version for your project (example: lts-12.26 uses gtk2hs-buildtools-0.13.4.0). In your package.yaml, in the dependencies section write the entry entry - gtk2hs-buildtools
From lts-13.11 and above gtk2hs-buildtools is not available in stackage, so you need to add it as an extra-dep. in the stack.yaml, in the section extra-dep add the following entry gtk2hs-buildtools-0.13.4.0 (or the version number you'd like to use). Then add in the package.yaml and entry gtk2hs-buildtools. It is necessary to add the entry in both files. Refer to stack docs o understand why.
Just to ensure you can build your project, your files should something look like the following:
if using resolver above or equal to 13.11
stack.yaml
resolver: lts-13.11
extra-deps:
- gtk2hs-buildtools-0.13.4.0
package.yaml
dependencies:
- base
- gtk2hs-buildtools
if using resolver below 13.11
stack.yaml
resolver: lts-12.26
extra-deps:
package.yaml
dependencies:
- base
- gtk2hs-buildtools
I am attempting to build a project which uses Euterpea.
Running stack build I get the following error, suggesting that I need to add Euterpea to the build-depends section of my .cabal file.
$ sb
composition-0.1.0.0: build (lib + exe)
Preprocessing library composition-0.1.0.0...
[2 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/Lib.o )
/home/matthew/backup/composition/composition/src/Lib.hs:5:1: error:
Failed to load interface for ‘Euterpea’
It is a member of the hidden package ‘Euterpea-2.0.4’.
Perhaps you need to add ‘Euterpea’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
-- While building package composition-0.1.0.0 using:
/home/matthew/.stack/setup-exe-cache/x86_64-linux-nix/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0 build lib:composition exe:composition-exe --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
I add Euterpea there, and the library section of my .cabal file then is the following.
library
hs-source-dirs:
src
build-depends: base >= 4.7 && < 5
, Euterpea
exposed-modules:
Lib
other-modules:
Paths_composition
default-language: Haskell2010
However, when I then run stack build again, it gives the same error -- and changes my .cabal file back to what it was originally, with the library section then looking like
library
hs-source-dirs:
src
build-depends:
base >= 4.7 && < 5
exposed-modules:
Lib
other-modules:
Paths_composition
default-language: Haskell2010
Why is stack build altering my cabal file? I have never seen that occurring before.
Side note:
Not sure if it is related, but the .cabal file's format appears to be different than it normally does. Here as with previous projects I auto-initialized by running stack new <project-name>. I don't know what I might have done different from previous projects to cause this unexpected behavior of stack build.
Make sure package.yaml exists in the root of your project directory.
package.yaml is a new file format to improve the syntax of cabal, converted by hpack.
Stack supports hpack as strongly as the stack build command automatically converts package.yaml into a cabal file with hpack command.
So, delete package.yaml or edit package.yaml to add Euterpea package.
Editing it would not be so difficult as its format is YAML.
I want to add to the YAMAMOTO Yuji's answer. The solution is absolutely right. But I just wanted to add few things, it is not hard to edit the package.yaml.
Step 1 : The trickiest part is finding the correct package name.
Use Hoogle or Stackage to find the package where the module
resides. Read more about how to find package name in this post.
Step 2 : Now you have to open the package.yaml file and add the package name. In your case add 'Euterpea' package in the list of dependencies.
dependencies:
...
- your-package-name
Please note that Euterpea package has to be added in a different way. Please read this
post for better understanding.
Step 3 : Open project-name.cabal in project root and add required package name under build-depends:
library
hs-source-dirs:
src
build-depends:
base >= 4.7 && < 5
, your-package-name
exposed-modules:
Lib
Step 4 :Issue stack build to download and build dependencies
(or stack ghci if you plan to use it in the REPL)
Hope this works! Happy coding! :)
I am working on the "roman-numerals" task from the exercism Haskell track and followed their instructions to installing stack. I am working on a Fedora 24 box.
As long as I was working with Haskell modules from base, I didn't have a problem. Now I am trying to import the Data.Map module. It works fine using the ghci command line:
$ ghci
GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> import Data.Map
Prelude Data.Map>
However, when I try to import it from inside my src file with the command:
import qualified Data.Map as M (foldlWithKey, fromList)
I am running into problems when I try to run the test:
$ stack test
roman-numerals-0.0.0: build (lib + test)
Preprocessing library roman-numerals-0.0.0...
[2 of 2] Compiling Roman (...)
(...) /roman-numerals/src/Roman.hs:3:1: error:
Failed to load interface for ‘Data.Map’
It is a member of the hidden package ‘containers-0.5.7.1’.
Perhaps you need to add ‘containers’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
Progress: 1/2
(...)
I googled the problem and found a straightforward solution at the Cabal FAQ at haskell.org:
What you need to do is to add containers to the build-depends in your .cabal file.
I am assuming they mean the file roman-numerals.cabal that is in my working directory. The contents are:
-- This file has been generated from package.yaml by hpack version 0.14.0.
--
-- see: https://github.com/sol/hpack
name: roman-numerals
version: 0.0.0
build-type: Simple
cabal-version: >= 1.10
library
hs-source-dirs:
src
build-depends:
base
exposed-modules:
Roman
other-modules:
Paths_roman_numerals
default-language: Haskell2010
test-suite test
type: exitcode-stdio-1.0
main-is: Tests.hs
hs-source-dirs:
test
build-depends:
base
, roman-numerals
, hspec
default-language: Haskell2010
I tried to add "containers" to the build-depends in either and both the "library" and "test-suite" sections, but when I run
$ stack test
the error persists, and the .cabal file is reverted to the same contents shown above.
Any pointers? Much appreciated!
This is hinting at the problem:
-- This file has been generated from package.yaml by hpack version 0.14.0.
--
-- see: https://github.com/sol/hpack
hpack is an alternative, YAML-based specification format for Haskell packages which can be used instead of the traditional cabal format. The hpack program can then be used to convert a specification from the hpack format to the cabal format to be able to integrate with the rest of the Haskell toolchain.
Some basic support for hpack was added to stack some time ago. It checks for a file called package.yaml in the current directory, which is the standard name for hpack format package specifications, and if it exists, it runs hpack to convert it to a cabal file and then proceeds building as normal. This is what's trampling over your .cabal file.
To solve this, either:
Modify package.yaml instead of roman-numerals.cabal to achieve the same effect.
Delete package.yaml and continue working directly with roman-numerals.cabal.
The syntax for adding dependencies in the hpack format is:
dependencies:
- base
- containers
Here's a .cabal file:
Name: myprogram
Version: 0.1
-- blah blah blah
Cabal-version: >=1.9.2
Executable myprogram
HS-source-dirs: src
Main-is: Main.hs
Build-depends: attoparsec == 0.10.*,
base == 4.3.*,
-- long long list of packages
Test-Suite test
HS-source-dirs: test, src
Type: exitcode-stdio-1.0
Main-is: Main.hs
Build-depends: attoparsec == 0.10.*,
base == 4.3.*,
-- long long list of packages
QuickCheck == 2.4.*
Is there any way I can replace the long list of build-depends packages for the test suite with "same as for the executable, plus QuickCheck"?
Edit: version information.
cabal-dev 0.9
cabal-install 0.10.2
Cabal library 1.10.2.0
GHC 7.0.4
Haskell Platform 2011.4.0.0
NOTE: superseded by phadej's answer suggesting common stanzas.
Is there any way I can replace the long list of build-depends packages for the test suite with "same as for the executable, plus QuickCheck"?
Not that I know of. However, there is a way to only mention the list of build-depends packages once, by structuring your project into three targets:
a library that contains all your code, and needs the long build-depends list.
an executable that consists of only one file, and depends on base and the library from above.
a test-suite that depends on the library from above, and the testing packages you are using.
Maybe this approach is what indygemma's answer proposes, but the Cabal file proposed there will not quite achieve it, as Norman Ramsey points out in a comment. Here's the main points of what you need in a Cabal file. For a full example that works for me, you can look at this Cabal file.
name: my-program
version: ...
library
hs-source-dirs: src-lib
build-depends: base, containers, ...
exposed-modules: My.Program.Main, ...
executable my-program
hs-source-dirs: src-exec
main-is: my-program.hs
Build-depends: base, my-program
test-suite tests
type: exitcode-stdio-1.0
hs-source-dirs: src-test
main-is: tests.hs
other-modules: ...
build-depends: base, my-program, test-framework, ...
Important points:
There are three separate source directories for the three targets. This is necessary to stop GHC from recompiling library files when building the other targets.
All of the application code is in the library. The executable is just a wrapper, like this:
import My.Program.Main (realMain)
main = realMain
The library exposes all modules that are necessary for testing.
The last point highlights the drawback of this approach: You end up having to expose internal modules. The main benefit of this approach is that you have less duplication in the Cabal file, and maybe more importantly, less duplication in the build process: The library code will be built only once, and then linked into both the executable and the test-suite.
Since version 2.2 Cabal supports common stanzas, to dedup build info fields:
https://cabal.readthedocs.io/en/latest/developing-packages.html#common-stanzas
cabal-version: 2.2
name: myprogram
version: 0.1
-- blah blah blah
common deps
build-depends: base ^>= 4.11,
-- long long list of packages
ghc-options: -Wall
library
import: deps
exposed-modules: Foo
test-suite tests
import: deps
type: exitcode-stdio-1.0
main-is: Tests.hs
build-depends: foo
You could also consider using hpack instead of writing the .cabal file by hand:
In hpack's package.yaml format, you can specify a common dependencies field whose entries are added to every components' build-depends field when generating the .cabal file.
For example, see hpack's own package.yaml and the generated hpack.cabal.
To start using hpack with an existing package, you can use hpack-convert which will generate the package.yaml from an existing .cabal file.
To create a new package that uses hpack, you can use stack's simple-hpack template like so: stack new mypkg simple-hpack.
If you use stack for development, you don't have to call hpack manually to regenerate the .cabal file from an updated package.yaml – stack will do that automatically.
No easy way:
you can use m4 and specify your dependencies once, but then you will need to reprocess your Cabal file through m4 whenever you change it.
you can move the code you are testing out to a library, and then specify the library in your Build-depends for the test. That requires you to install a library even just to run the test.
You can just not put the test in the cabal file at all. Build it with ghc --make, which will pull in dependencies. But then you lose cabal integration.
There is an optional library section for .cabal files, which solves your problem.
name: myprogram
version: 0.1
-- blah blah blah
cabal-version: >=1.9.2
library
build-depends: attoparsec == 0.10.*
, base == 4.3.*
-- long long list of packages
executable myprogram
hs-source-dirs: src
main-is: Main.hs
test-suite test
hs-source-dirs: test, src
type: exitcode-stdio-1.0
main-is: Main.hs
build-depends: QuickCheck == 2.4.*