Is there a way to run my test suites with my build command? All I can find is that I can run e.g. cabal test after cabal build. What I want is a way to automatically run my tests when running e.g. cabal build.
I want a solution that will automate this for anyone building the package without requiring them to run a different script. An analogy would be a java build script where the default build target runs unit tests after compiling.
You can use a cabal.project.local to do this when using cabal v2 projects (as in, cabal v2-build which is the default and thus the same as cabal build for cabal version 3.0 and up).
The strategy is just to place a cabal.project.local file in the build directory with contents of:
tests: true
I find this a really bad idea since it's unexpected, non-canonical behavior that breaks cross-compilation, but you can probably hack it together with a Custom build type.
Here's an example mypackage.cabal:
cabal-version: >=2.0
name: mypackage
version: 0.1.0.0
author: None
maintainer: none#example.com
build-type: Custom
custom-setup
setup-depends:
base >= 4.5,
Cabal >= 2.0
executable mypackage
main-is: Main.hs
build-depends: base >= 4
default-language: Haskell2010
test-suite test
type: exitcode-stdio-1.0
build-depends: base >= 4
main-is: Test.hs
and a corresponding Setup.hs:
import Control.Monad
import Distribution.Simple
import Distribution.Simple.Setup
import Distribution.Simple.Test
import Distribution.Simple.Build
main = defaultMainWithHooks simpleUserHooks {
postBuild = myPostBuild
}
myPostBuild args flags desc info =
when ("exe:mypackage" `elem` buildArgs flags) $ do
build desc info defaultBuildFlags { buildDistPref = buildDistPref flags } []
test ["test"] desc info defaultTestFlags {
testDistPref = buildDistPref flags
}
This does result in a project where cabal build also builds and runs the tests on my Cabal 3.0.0.0 system, but I don't know which additional caveats this has.
Hello i am trying to use a module inside another module but it seems it just won't work.I tried updating the cabal file,stack,i reinstalled the platform,ghc and everything and it just won't let it import modules.I tried adding in the cabal file both other-modules and home-modules section ..to no effect.What could be the problem?
Modules:
module Test where
test::IO()
test=do
elem<-getLine
print elem
module Main where
import Test
main :: IO ()
main = do
putStrLn "hello world"
Cabal-build renders this error:
$ cabal build
Resolving dependencies...
Configuring console-0.1.0.0...
Warning: To use the 'default-language' field the package needs to specify at
least 'cabal-version: >= 1.10'.
Preprocessing executable 'console' for console-0.1.0.0..
Building executable 'console' for console-0.1.0.0..
<no location info>: warning: [-Wmissing-home-modules]
These modules are needed for compilation but not listed in your .cabal file's other-modules: Test
<no location info>: warning: [-Wmissing-home-modules]
These modules are needed for compilation but not listed in your .cabal file's other-modules: Test
When i build with Stack i get this error:
C:\<path>\Main.hs:4:1: error:
Failed to load interface for `Test'
Use -v to see a list of the files searched for.
Failed, modules loaded: none.
H>>= :module + *Main
Cabal file:
name: console
version: 0.1.0.0
-- synopsis:
-- description:
homepage: https://github.com/githubuser/console#readme
license: BSD3
license-file: LICENSE
author: Bercovici Adrian Simon
maintainer: example#example.com
copyright: 2018 Bercovici Adrian Simon
category: Web
build-type: Simple
cabal-version: >=1.2
extra-source-files: README.md
Executable console
hs-source-dirs: src
main-is: Main.hs
default-language: Haskell2010
build-depends: base >= 4.7 && < 5
other-modules: Test
The other-modules: directive must go inside the Executable console stanza.
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
I try to generate documentation for my executable using cabal haddock. My project structure looks like this:
~/.../project_name
project_name.cabal
Setup.hs
src/
Main.hs
Data/
...
test/
MainTestSuite
...
When I run cabal haddock --executable it fails with the following error message:
module ‘projects-0.1.0.0:Main’ is defined in multiple files: dist/build/tmp-8215/src/Main.hs
dist/build/tmp-8215/./Setup.hs
The Source.hs file has these contents:
import Distribution.Simple
main = defaultMain
The ghc Version is 7.8.3 and the haddock version is 2.14.3.
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.*