cabal dependency build fails - haskell

hello I am new to haskell/cabal so this might be a stupid question but i couldn't find it anywhere.
When I try to build a cabal package it correctly list the dependencies.
cabal build main
In order, the following will be built (use -v for more details):
- dependency-1.0
cabal: Failed to build dependency-1.0
so then I do
cabal build dependency
and it build fine listing the correct version. I go back to cabal build main and it still fails. And what is more weird when I go to build the dependency again it says build required
There are 2 questions. Why would it fail in the main if it build by itself just fine. And also even if I run cabal build dependency over and over it always says build required, like it isn't caching anything? Is this normal?

Related

Stack: 'hdevtools is a library dependency, but the package provides no library needed since my-app is a build target.'

I was trying to add hdevtools to my stack project, so I ran stack build hdevtools. The install seemed to work successfully, and my text editor stopped reporting imported libraries installed via stack (like aeson and tasty) as missing.
However, things went wrong when I added this line to the dependencies section of my package.yaml file:
- hdevtools >= 0.1 && < 1
And then tried to run stack build again. I received the following error output:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for my-app-name-0.1.0.0:
hdevtools is a library dependency, but the package provides no library
needed since my-app-name is a build target.
Some different approaches to resolving this:
* Consider trying 'stack solver', which uses the cabal-install solver to attempt
to find some working build configuration. This can be convenient when dealing
with many complicated constraint errors, but results may be unpredictable.
Plan construction failed.
I tried running stack solver, but that threw the exception documented here.
How can I declare hdevtools as a dependency of my project?
#alexis-king recommends using stack build --copy-compiler-tool hdevtools in this guide, in the section titled Setting up editor integration.
This works for the current project, and other projects using the same GHC version, but you will need to run it again when you upgrade to a new GHC version.
More context from King's guide:
As mentioned above, stack install is not what you want. Tools like ghc-mod, hlint, hoogle, weeder, and intero work best when installed as part of the sandbox, not globally, since that ensures they will match the current GHC version your project is using.
How can I declare hdevtools as a dependency of my project?
hdevtool is an executable and cabal doesn't have a concept of development dependencies (like in other package managers like npm etc). So, all you can do is install hdevtools globally and make it work.

Travis build failing after a cabal check warning

Several builds, like this one, fail when executing cabal check:
++cabal check
These warnings may cause trouble when distributing the package:
* 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your users.
However, most of the other builds in the matrix do not fail after this check.
I'm using the complex Travis configuration suggested at the stack docs, and this is the Travis configuration specific for the project I'm trying to get on CI.
Any ideas on what might be causing this behavior?
There are two types of build in your travis config:
Stack based build
Cabal based build
If you follow the script code, you will see that only Cabal based build has the command cabal check in it. That will explain why all of your Stack based builds are working fine. Now, let's see the cabal check command line in detail:
cabal check || [ "$CABALVER" == "1.16" ]
So, if your installed cabal version is 1.16, it will ignore the output of cabal check and that command is treated as a success. And infact, that's what is happening. Only one Cabal based build job is success in your travis, because it's version is 1.16.

Prevent rebuilding external dependency

I'm new to Haskell.
I cloned a Haskell project (pandoc) from github, and compiled it with:
stack setup
stack install --test
After a while, the project is built.
Now I want to build another project (pandoc-crossref), an extension to the first one and which depends on it.
There is an extra-deps entry for pandoc in stack.yaml:
extra-deps:
...
- pandoc-2.0.1.1
...
In the README.md of the pandoc-crossref project I can see:
Pandoc will also be built, if it's not installed as a Haskell library system-wide.
But when I try to build pandoc-crossref, pandoc is built again.
What does installed as a Haskell library system-wide mean? Is it possible to prevent the first project being built again? Maybe by using the --extra-lib-dirs option?

Stack init package not found

When trying to build an existing project with Stack I got errors like
bv not found
- Genesis requires >=0.3 && <0.4 && -any
- exp requires -any
during stack init. The packages are all installed in a sandbox and are from hackage. I'm almost sure Stack doesn't look into the sandbox, but why can't it find the packages from hackage? I'm also able to build just by running cabal build.
stack does not look at Hackage at first. It tries to build your project using only packages from a snapshot of Stackage (you can find the exact snapshot you are using in the resolver field of stack.yaml). bv does not seem to be in Stackage (at least it is not in the latest LTS snapshot). Fortunately, the issue is easy to solve: just run stack solver --modify-stack-yaml. That will identify all non-Stackage dependencies and add them to the extra-deps field of stack.yaml. From that point on, those dependencies will be built somewhere in the .stack-work subdirectory of your project, in a very similar way to packages in a cabal-install sandbox.

How to build a sandboxed cabal project with a custom version of a dependency that is not on hackage (e.g. a checkout from github)

If a have a library checked out locally that builds with cabal that is used by an application. I would like to build my application against the the local library rather than something from hackage but I'm not sure how to do this. This seems like something I should be able to do, I'm just don't seem to be able to work out how.
Sandboxing
In case it matters or complicates things, the application is in a cabal sandbox with the cabal-sandbox-config file in the route directory of the application.
What I'm Trying to accomplish
I'm building Yesod application and I want to tweak the behaviour of one of the dependencies (shakespeare). I would like to build my application against my tweaked version.
Use cabal sandbox add-source, which is designed specifically for this use case.
Example:
$ git clone https://github.com/SomeUser/SomeDependency
$ cd /path/to/my-project
$ cabal sandbox add-source /path/to/SomeDependency
$ cabal build
As a bonus, if you later update SomeDependency and try to rebuild my-project, cabal will notice that and reinstall SomeDependency.
Option 1:
You can just clone the project, and then run a cabal install in the cloned directory.
git clone https://github.com/yesodweb/shakespeare.git
This will give you a directory shakespeare which will contain a .cabal file.
So just enter the directory and run a cabal install. This will install shakespeare. Now continue with installing your project.
The key point:
You need to install shakespeare yourself first so that when you compile your own project, ghc or cabal doesn't try to install the shakespeare dependency (from hackage by default) on its own.
Option 2:
Install hackage-server
Upload a copy of shakespeare (your tweaked version) to your local hackage
Edit your cabal config to prioritize your local hackage over the haskell-hackage
remote-repo: hackage.haskell.org:http://hackage.haskell.org/packages/archive
remote-repo: local.hackage:http://local.hackage/packages/archive
This might make sense if you're going to be tweaking several packages, but you're probably better off not doing this because among other things, keeping track of updates to your tweaked versions is going to be a nightmare.

Resources