Why does
stack bench builds (and run)
and
stack build mypackage:bench tells me
Cabal-simple_mPHDZzAJ_3.4.1.0_ghc-9.0.2: No benchmarks enabled. Did
you remember to configure with '--enable-benchmarks'?
Related
I'm trying to separate the stages of building my package and its dependencies in a sequence of uses of stack build but have become a bit disoriented by all the combinations of flags that seem relevant. My goal is to separately:
Build package dependencies only
Build testing dependencies only
Build the package, only
Run tests (with everything already built)
stack --resolver XXX build --no-run-tests--no-run-benchmarks --only-dependencies
stack --resolver XXX build --no-run-tests --no-run-benchmarks
stack --resolver XXX build --no-run-tests --no-run-benchmarks --test --bench
stack --resolver XXX build --test --no-run-benchmarks
Which isn't quite the right order and does't feel quite right. I'd also ideally like to have additional steps for documentation:
Build package dependencies only
Build testing dependencies only
Build Haddock dependencies only
Build the package, only
Run tests (with everything already built)
Build Haddock, with doctests
What sequence of commands and combinations of flags would accomplish these steps?
After invoking
stack new foo
stack build foo:test:foo-test --test --fast --no-copy-bins --no-copy-compiler-tool
Stack is still copying and installing library and executables:
foo> copy/register Installing library in
/tmp/foo/.stack-work/install/x86_64-linux-tinfo6/c2ce3190a19b85be796c6c0a3948129db378f9cd184b6b091f74bef68e262808/8.8.4/lib/x86_64-linux-ghc-8.8.4/foo-0.1.0.0-JFvztN1xJpOHaq2zHLpyHS
Installing executable foo-exe in
/tmp/foo/.stack-work/install/x86_64-linux-tinfo6/c2ce3190a19b85be796c6c0a3948129db378f9cd184b6b091f74bef68e262808/8.8.4/bin
Registering library for foo-0.1.0.0..
How can I disable copying of executables during stack build --test? I have a project with dozen of executables and copying of them takes longer than executing tests...
% stack --version
Version 2.5.1, Git revision d6ab861544918185236cf826cb2028abb266d6d5 x86_64 hpack-0.33.0
I'm trying to test my Haskell package against several Stackage resolvers on Travis, but my --resolver environment variable is being ignored.
For example, if I specify
env:
- ARGS="--resolver lts-4.0"
in my .travis.yml, I still still seem to be using a different resolver (the one in my stack.yaml?) and GHC, as shown by lines like
Installing library in
/home/travis/build/orome/crypto-enigma-hs/.stack-work/install/x86_64-linux/lts-9.1/8.0.2/lib/x86_64-linux-ghc-8.0.2/crypto-enigma-0.0.2.9-6Cs7XSzJkwSDxsEMnLKb0X
in the corresponding build log, which indicates a different resolver (9.1), and corresponding GHC (8.0.2) being used.
How should my build (stack.yaml, .travis.yml, etc.) be configured to ensure that the resolvers (and corresponding GHC) I specify are used to preform my Travis builds and tests?
With env you just define environment variables. You still have to use them. stack on its own does not respect the ARGS variable, so use it in your script, e.g.
install:
# Build dependencies
- stack $ARGS --no-terminal --install-ghc test --only-dependencies
script:
# Build the package, its tests, and its docs and run the tests
- stack $ARGS --no-terminal --install-ghc test --haddock --no-haddock-deps
You should probably use a better name, for example RESOLVER:
env:
- RESOLVER=lts-4.0
- RESOLVER=lts-6.0
- RESOLVER=lts-8.0
install:
# Build dependencies
- stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies
script:
# Build the package, its tests, and its docs and run the tests
- stack --resolver $RESOLVER --no-terminal --install-ghc test --haddock --no-haddock-deps
Also keep in mind that it's usually a better idea to use multiple stack.yml to hold the configuration for that specific LTS variant.
For more information, see stack's Travis documentation and Travis' environment variables documentation.
I am trying to setup my Haskero (Visual Studio Code extension that uses Intero) for my Haskell project, yet I get the following error :
app\Main.hs:3:1: error:
Failed to load interface for `Lib'
Use -v to see a list of the files searched for.
Steps to reproduce:
stack new project
cd project
stack build intero
stack exec intero
> :l app/Main.hs
app/Main.hs :
module Main where
import Lib
main :: IO ()
main = someFunc
src/Lib.hs :
module Lib
( someFunc
) where
someFunc :: IO ()
someFunc = putStrLn "someFunc"
I had similar issue occuring in Visual Studio Code.
Under the hood Haskero properly uses:
stack ghci --with-ghc intero --no-build --no-load
However Haskero assumes that the stack project is the working directory loaded to VSCode. If instead the stack project is one of the subdirectories then the same error appears in IDE, because stack command is run from that main directory. At least it's what happens currently with Haskero 1.3.1.
The solution is to always make sure that stack project is equal to working directory in VSCode.
I don't have experience with Haskero but can duplicate the problem with a plain old Intero installation on a Linux machine.
The issue is that you're invoking the Intero backend via stack exec instead of stack ghci. You would observe the same problem if you tried using stack exec ghci instead of stack ghci to invoke a usual GHC interactive session (see the documentation for stack ghci for more information).
Instead of stack exec intero, try:
stack ghci --with-ghc intero --no-build --no-load
and it should work okay.
(Note that stack exec intero actually works okay if you stack build your project first, but the interactive session is still supposed to be invoked via stack ghci.)
I followed "Yesod quick start guide" to install Yesod in Windows 10.
But, when I issued the stack build command, it failed.
Environment
Windows 10 (64bits)
stack-0.1.5 (for Windows10 64bits)
No Haskell Platform
I executed these commands
stack new my-project yesod-sqlite && cd my-project
stack install yesod-bin cabal-install --install-ghc
stack setup
stack build <--- the error occured
In 'stack build' command, the package installations were done. But, when it build the project, the error occured.
Command Prompt
>stack build
Setting codepage to UTF-8 (65001) to ensure correct output from GHC
my-project-0.0.0: build
Preprocessing library my-project-0.0.0...
In-place registering my-project-0.0.0...
Preprocessing executable 'my-project' for my-project-0.0.0...
Linking .stack-work\dist\x86_64-windows\Cabal-1.22.4.0\build\my-project\my-project.exe ...
ghc.exe: could not execute: C:\Users\xxxxx\AppData\Local\Programs\stack\x86_64-windows\ghc-7.10.2\lib/../mingw/bin/gcc.exe
-- While building package my-project-0.0.0 using:
C:\Users\xxxxx\AppData\Roaming\local\bin\stack-0.1.5.0\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.10.2.exe --builddir=.stack-work\dist\x86_64-windows\Cabal-1.22.4.0\ build lib:my-project exe:my-project --ghc-options -ddump-hi -ddump-to-file
Process exited with code: ExitFailure 1
This is caused by the argument length limit on Windows. Starting in GHC 7.10.3, GHC will support response files for sending linker arguments in order to bypass this limitation. In the meanwhile, a workaround is to manually make the path to your stack root shorter by setting the STACK_ROOT environment variable.
For more information, see https://www.fpcomplete.com/blog/2015/08/stack-ghc-windows