I'm running my first "cabal test" for Haskell, but I get the error:
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring sample-0.1.0.0...
cabal: At least the following dependencies are missing:
base ==4.7.*
sampel.cabal:
-- Initial sample.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
name: sample
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.10
executable SampleTest
main-is: SampleTest.hs
build-depends: base >= 4.7 && <4.8, HUnit >=1.2 && <1.3
hs-source-dirs: test, src
default-language: Haskell2010
Any help appreciated.
Versions of GHC come bundled with versions of base. GHC 7.10.2 uses base 4.8.1.0.
Your cabal must be using a slightly out of date template....
You should either change the range of acceptable base version (as you did in your comment above), or use a different version of GHC.
Related
I'm using inline-c and I have two C files that I'd like to call in the Haskell code. In the Cabal file, there are:
include-dirs: cbits
, /usr/local/include
c-sources: cbits/genann.c
In the Cbits directory, there's also genann.h
I can build and run the project without problem but when I do cabal install, the compiler complain that it can't find the C header file.
I checked the Cabal manual and added the following options:
includes: cbits/genann.h
install-includes: cbits/genann.h
This time I got:
Configuring executable 'inline-gsl' for inline-gsl-0.1.0.0..
cabal-3.6.2.0: Missing dependency on a foreign library:
* Missing (or bad) header file: cbits/genann.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
Where is wrong here? Do I need to compile the C code into object code and put them in the system?
The complete Cabal file:
cabal-version: 2.4
name: inline-gsl
version: 0.1.0.0
-- A short (one-line) description of the package.
-- synopsis:
extra-source-files: CHANGELOG.md
executable inline-gsl
main-is: Main.hs
build-depends: base ^>=4.14.3.0
, inline-c
, vector
, massiv
, array
, bytestring >= 0.10
, template-haskell
hs-source-dirs: app
pkgconfig-depends: glib-2.0, gtk4, gsl
default-language: Haskell2010
extra-libraries: m, tensorflow
extra-lib-dirs: /usr/local/lib
cc-options: -Wall -m64 -O4
include-dirs: cbits
, /usr/local/include
includes: cbits/genann.h
install-includes: cbits/genann.h
c-sources: cbits/genann.c
I can build and run the project without problem but when I do cabal install, the compiler complain that it can't find the C header file.
I believe this indicates that the problem is that your header files are not included in your package source tarballs (sdist). You need to list all non-Haskell source files under the extra-source-files field in your cabal file:
extra-source-files: CHANGELOG.md, cbits/genann.h, cbits/genann.c
In my haskell project, I have the following directory structure (some entries are missing but not relevant to this problem)
- quanthas
- quanthas.cabal
- src/
- QuantHas/
- Settings.hs
My Settings.hs file contains this module header
module QuantHas.Settings(module QuantHas.Settings) where
My cabal file looks like this
Name: QuantHas
Version: 0.0
Description:
QuantHas project is an attempt to port QuantLib to Haskell keeping the functional flavor of Haskell.
License: BSD3
License-file: LICENSE
Build-Type: Simple
Cabal-Version: >=1.10
Library
Build-Depends: base >= 3 && < 5, array >= 0.2
Exposed-modules: QuantHas.Time.Frequency
QuantHas.Time.TimeUnit
QuantHas.Time.Period
QuantHas.Time.Date
QuantHas.Time.DayCounter
QuantHas.Time.BusinessDayConvention
QuantHas.Time.Calendar
QuantHas.Time.Calendars.UnitedKingdom
QuantHas.Time.Schedule
QuantHas.Settings
QuantHas.Require
default-language: Haskell2010
hs-source-dirs: src
-- ghc-options: -Wall
test-suite QuantHas-tests
type: exitcode-stdio-1.0
hs-source-dirs: testsuite
main-is: Tests.hs
default-language: Haskell2010
When I execute
cabal install --enable-tests
I get this message
src/Quanthas/Settings.hs:17:8: error:
File name does not match module name:
Saw: ‘QuantHas.Settings’
Expected: ‘Quanthas.Settings’
This seems wrong. However, what if we do what cabal expects. So the Settings.hs module header now is
module Quanthas.Settings(module Quanthas.Settings) where
Cabal now says
src/QuantHas/Settings.hs:17:8: error:
File name does not match module name:
Saw: ‘Quanthas.Settings’
Expected: ‘QuantHas.Settings’
And it's at this ppint that I give up and turn to SO. Can anyone help me understand what is going on?
Versions info:
Platform: Macbook Pro running MacOS 10.12.3
Haskell: 8.0.1
Cabal: 1.24.0.0
Thanks!
The issue is that there is a typo in one of the import statements in a different module. Since you're on a case-insensitive filesystem (OS X), GHC is able to find the module contents, but upon checking the module header finds it mismatches with the import statement and errors out.
Today I installed windows 8.1 and haskell on my laptop. I'm trying to build my own haskell library, but I got an error when I try to use cabal sdist. This is the error:
D:\Development\School\AFP\Assignments\Practice\Exercise\Project>cabal sdist
Distribution quality errors:
'license: NONE' is not a recognised license. The known licenses are: GPL,
GPL-2, GPL-3, LGPL, LGPL-2.1, LGPL-3, AGPL, AGPL-3, BSD2, BSD3, MIT, ISC,
MPL-2.0, Apache, Apache-2.0, PublicDomain, AllRightsReserved, OtherLicense
Distribution quality warnings:
No 'category' field.
No 'maintainer' field.
No 'synopsis' field.
A 'license-file' is not specified.
When distributing packages it is encouraged to specify source control
information in the .cabal file using one or more 'source-repository' sections.
See the Cabal user guide for details.
Note: the public hackage server would reject this package.
Warning: Cannot run preprocessors. Run 'configure' command first.
Building source dist for Project-0.1.0.0...
cabal: does not exist
Before I used the "cabal sdist" I used the following commands:
cabal init
cabal sandbox init
cabal install -j
Every command succeed, except for the cabal sdist. The cabal install only gives the following warning:
D:\Development\School\AFP\Assignments\Practice\Exercise\Project>cabal install -j
Resolving dependencies...
In order, the following will be installed:
Project-0.1.0.0 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Notice: installing into a sandbox located at
D:\Development\School\AFP\Assignments\Practice\Exercise\Project\.cabal-sandbox
Configuring Project-0.1.0.0...
Building Project-0.1.0.0...
Installed Project-0.1.0.0
This is my Project.cabal file:
-- Initial Project.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
-- Initial Project.cabal generated by cabal init. For further
-- documentation, see http://haskell.org/cabal/users-guide/
name: Project
version: 0.1.0.0
-- synopsis:
description: Education
license: NONE
-- license-file:
-- author:
-- maintainer:
-- copyright:
-- category:
build-type: Simple
extra-source-files: File6, File5, File4, File3, File2
cabal-version: >=1.10
library
exposed-modules: File1
-- other-modules:
-- other-extensions:
build-depends: base >=4.8 && <4.9, QuickCheck >=2.8 && <2.9
hs-source-dirs: src
default-language: Haskell2010
I tried google, but I can't find a good solution. I use the following versions:
Cabal version: 1.22.4.0
Haskell version: 7.10.2
If you need more information, please ask.
I don't know anything about sdist, but the problem is clear: you've specified 'NONE' as the license in your cabal file, but that is not allowed for the sdist option. configure, build, and init don't care about the specific license, but sdist apparently does.
For more info, I searched google for "cabal sdist" and found this.
This [cabal sdist] has the advantage that Cabal will do a bit more checking, and ensure that the tarball has the structure that HackageDB expects.
HackageDB probably expects a valid license, hence why "NONE" is not allowed.
The problem was that cabal could not find the files in extra-source-files. I thought I didn't had to add the extension of the haskell files, but this is required.
I also had another problem. The extra-source-files wasn't using the hs-source-dirs, so I had to explicitly write "src/" infront of a file.
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.*
I've got the following question:
I've got two Haskell libraries that depend on each other, and both libraries are managed by cabal. The corresponding cabal files look like this:
Library 1:
name: Lib1
version: 0.1
cabal-version: >=1.2
build-type: Simple
author: Matthias
library
hs-source-dirs: src
build-depends:
base >= 4,
Lib2
ghc-options: -Wall
exposed-modules: <...>
Library 2:
name: Lib2
version: 0.1
cabal-version: >=1.2
build-type: Simple
author: Matthias
library
hs-source-dirs: src
build-depends:
base >= 4,
Lib1
ghc-options: -Wall
exposed-modules: <...>
Installing one of the libraries (here library 2) with cabal install works:
Resolving dependencies...
In order, the following will be installed:
Lib2-0.1 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring Lib2-0.1...
Building Lib2-0.1...
Preprocessing library Lib2-0.1...
Registering Lib2-0.1...
Installing library in
C:\Users\Matthias\AppData\Roaming\cabal\Lib2-0.1\ghc-7.4.2
Registering Lib2-0.1...
But trying to install the other library (here library 1) with cabal install results in a dependency error:
Resolving dependencies...
cabal.exe: Could not resolve dependencies:
trying: Lib1-0.1 (user goal)
next goal: Lib2 (dependency of Lib1-0.1)
rejecting: Lib2-0.1/installed-aa4... (package is broken)
Is there any way to handle two such libraries that depend on each other so that I don't get dependency errors or is cabal simply not able to handle such a case properly?
As the others have said, circular dependencies are never going to work in Cabal. It's hard enough to compile modules with circular dependencies, but packages are a hopeless cause.
It can be annoyingly difficult sometimes, but the only real solution is to find a way to break the circular dependency somehow.