I am trying to debug some compilation problem and I would like to know if it is possible to have non interleaving build steps, like displayed here.
$ stack build
string-conv-0.1: configure
string-conv-0.1: build
dotnet-timespan-0.0.1.0: configure
dotnet-timespan-0.0.1.0: build
servant-0.7: configure
string-conv-0.1: copy/register
dotnet-timespan-0.0.1.0: copy/register
servant-0.7: build
control-monad-omega-0.3.1: configure
control-monad-omega-0.3.1: build
swagger2-2.0.1: configure
control-monad-omega-0.3.1: copy/register
swagger2-2.0.1: build
eventstore-0.12.0.0: configure
eventstore-0.12.0.0: build
servant-0.7: copy/register
servant-client-0.7: configure
servant-client-0.7: build
servant-docs-0.7: configure
servant-docs-0.7: build
servant-client-0.7: copy/register
servant-server-0.7: configure
servant-server-0.7: build
servant-server-0.7: copy/register
servant-docs-0.7: copy/register
swagger2-2.0.1: copy/register
servant-swagger-1.0.3: configure
servant-swagger-1.0.3: build
servant-swagger-1.0.3: copy/register
eventstore-0.12.0.0: copy/register
pl-cqrs-0.1.0.0: configure
pl-cqrs-0.1.0.0: build
pl-cqrs-0.1.0.0: copy/register
pl-server-0.1.0.0: configure
pl-server-0.1.0.0: build
pl-server-0.1.0.0: copy/register
pl-wrapper-0.0.0: configure
pl-wrapper-0.0.0: build
pl-wrapper-0.0.0: copy/register
Completed 13 action(s).
You could override the number of jobs used to compile with
stack build --jobs=1
Without it
$ stack build
hnexus-models-0.1.0.0: configure
hnexus-models-0.1.0.0: build
key-doc-schema-0.1.0.0: configure
key-doc-schema-0.1.0.0: build
key-doc-schema-0.1.0.0: copy/register
key-doc-client-0.1.0.0: configure
hnexus-models-0.1.0.0: copy/register
key-doc-client-0.1.0.0: build
hnexus-mschema-0.1.0.0: configure
hnexus-mschema-0.1.0.0: build
...
with it
$ stack build --jobs=1
hnexus-models-0.1.0.0: configure
hnexus-models-0.1.0.0: build
hnexus-models-0.1.0.0: copy/register
hnexus-mschema-0.1.0.0: configure
hnexus-mschema-0.1.0.0: build
hnexus-mschema-0.1.0.0: copy/register
bnexus-mschema-0.1.0.0: configure
bnexus-mschema-0.1.0.0: build
bnexus-mschema-0.1.0.0: copy/register
bnexus-client-0.1.0.0: configure
bnexus-client-0.1.0.0: build
...
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 now learning hakyll static site generator with stack.
When I execute stack build in the directory of my Hakyll site to rebuild site.hs, stack also rebuilds and copy/register dependencies each time, as shown below:
$ stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0
$ grep -Ev '^[[:space:]]*#' stack.yaml | uniq
resolver: lts-11.4
packages:
- .
$ stack build
haddock-library-1.4.5: configure
haddock-library-1.4.5: build
haddock-library-1.4.5: copy/register
pandoc-2.1.2: configure
pandoc-2.1.2: build
pandoc-2.1.2: copy/register
pandoc-citeproc-0.14.3: configure
pandoc-citeproc-0.14.3: build
pandoc-citeproc-0.14.3: copy/register
hakyll-4.12.1.0: configure
hakyll-4.12.1.0: build
hakyll-4.12.1.0: copy/register
... and site.hs.compilation ...
This is odd to me, because I have never changed those packages.
The rebuild takes quite long even for very small changes on site.hs.
Why does stack rebuild those packages? And is there any way to reduce this rebuild time?
Thank you.
There is a discussion of this here https://github.com/commercialhaskell/stack/issues/3899 . It's a known issue triggered by newer versions of haddock using sub-libraries. There's a PR open fixing the issue, but it hasn't been merged yet.
I created a Yesod application using stack new project yesod-postgres. Beside the web application, I want to create another program which uses the same database model and database connection.
I added a second executable section (a copy of the first) in the cabal file with a different name and main-is: myprogram.hs. I can now run stack build && stack exec myprogram successfully.
The problem is that the build always takes more than 1 minute:
$ stack build
project-0.0.0: unregistering
yesod-persistent-1.4.0.6: configure
yesod-persistent-1.4.0.6: build
yesod-persistent-1.4.0.6: copy/register
yesod-form-1.4.9: configure
yesod-form-1.4.9: build
yesod-form-1.4.9: copy/register
yesod-auth-1.4.15: configure
yesod-auth-1.4.15: build
yesod-auth-1.4.15: copy/register
yesod-1.4.3.1: configure
yesod-1.4.3.1: build
yesod-1.4.3.1: copy/register
classy-prelude-yesod-0.12.8: configure
classy-prelude-yesod-0.12.8: build
classy-prelude-yesod-0.12.8: copy/register
project-0.0.0: build
Preprocessing library project-0.0.0...
In-place registering project-0.0.0...
Preprocessing executable 'myprogram' for project-0.0.0...
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/myprogram/myprogram ...
Preprocessing executable 'project' for project-0.0.0...
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/project/project ...
project-0.0.0: copy/register
Installing library in
/home/jakob/projects/project/project/.stack-work/install/x86_64-linux/lts-6.27/7.10.3/lib/x86_6
4-linux-ghc-7.10.3/project-0.0.0-1qruVQVcU0k2yXxF1Z1w7r
Installing executable(s) in
/home/jakob/projects/project/project/.stack-work/install/x86_64-linux/lts-6.27/7.10.3/bin
Registering project-0.0.0...
Completed 6 action(s).
How can I speed up the build process? How can I prevent stack from rebuilding the yesod dependencies every time?
This isn't specific to adding a second executable; it happens even with a fresh yesod-postgres project with a single executable.
Instead it appears to be a bug in Stack's lts-6.27 package set (and possibly others?). Here's a workaround. In your stack.yaml, add the following extra-dep:
extra-deps:
- yesod-persistent-1.4.0.6
and run stack build. Then, a second stack build should run without rebuilding anything.
I put stack.exe v0.1.2.2 in one of my PATH dirs, then install ghc-7.8.4 via stack setup.
I trying to install ghc-mod and obtain strange error Setup.hs: does not exist:
stack install ghc-mod
Using resolver: lts-2.21 from global config file: C:\Users\martynov_p\AppData\Roaming\stack\global\stack.yaml
ghc-paths-0.1.0.9: configure
data-default-class-0.0.1: configure
dlist-0.7.1.1: configure
ansi-terminal-0.6.2.1: configure
hscolour-1.22: configure
extra-1.1: configure
mtl-2.1.3.1: configure
cmdargs-0.10.13: configure
Progress: 8/54
-- While building package cmdargs-0.10.13 using:
C:\\Users\\martynov_p\\appdata\\Local\\Programs\\stack\\x86_64-windows\\ghc-7.8.4\\bin\\runhaskell.exe -package=Cabal-1.18.1.5 -clear-package-db -global-package-db -package-db=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\pkgdb\ C:\Users\MARTYN~1\AppData\Local\Temp\stack12088\Setup.hs --builddir=.stack-work\dist\x86_64-windows\Cabal-1.18.1.5\ configure --user --package-db=clear --package-db=global --package-db=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\pkgdb\ --constraint=base==4.7.0.2 --constraint=filepath==1.3.0.2 --constraint=process==1.2.0.0 --constraint=template-haskell==2.9.0.0 --constraint=transformers==0.3.0.0 --libdir=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\lib --bindir=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\bin --datadir=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\share --docdir=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\doc\cmdargs-0.10.13 --htmldir=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\doc\cmdargs-0.10.13 --haddockdir=C:\Users\martynov_p\AppData\Roaming\stack\snapshots\x86_64-windows\lts-2.21\7.8.4\doc\cmdargs-0.10.13
Process exited with code: ExitFailure 1
Logs have been written to: "C:\\Users\\martynov_p\\AppData\\Roaming\\stack\\global\\.stack-work\\logs\\cmdargs-0.10.13.log"
Configuring cmdargs-0.10.13...
Setup.hs: does not exist
This is probably due to a bug in cabal, and is resolved by upgrading your cabal version or switching to a newer stackage resolver. See
https://github.com/haskell/cabal/issues/1733
https://github.com/commercialhaskell/stack/issues/943