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.
Related
I'm trying to setup a new project using the nightly-2017-08-17 snapshot
stack new test --resolver nightly-2017-08-17
However this gives the following error:
Downloading template "new-template" to create project "test" in test/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- test/test.cabal
Selected resolver: nightly-2017-08-17
Unable to parse cabal file: FromString "This package requires at least Cabal version 2.0" Nothing
Cabal is in its latest version:
stack setup --upgrade-cabal
Currently installed Cabal is 2.0.0.2, newest is 2.0.0.2. I'm not upgrading Cabal.
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
Is this not the correct way of selecting this nightly snapshot with stack or is this a bug in the tool?
Cabal's file format has changed in the 2.0 release of it (likely because of backpack). You have to use Stack version >= 1.5.1 which bypasses this error. A proper fix for this will be likely released in the next version of Stack. IIRC, the fix is already in the master brach of the stack - so the upgrade via --source-only willl also work for you.
You can read the changelog here to know more information about it.
I'm following these instructions. I successfully did stack new and stack setup but stack build fails.
I found a git issue that this may be due to extra files listed in the cabal file, but removing them didn't fix the issue (and I'm just using the new-template without any changes). I am on Ubuntu 14.04 and installed stack using the script. Is there anything else I can look into?
It appears that this might be due to me trying to build inside of a cifs directory. Is there anything I can do to handle this?
# stack build
ehri-haskell-0.1.0.0: configure (lib + exe)
Configuring ehri-haskell-0.1.0.0...
ehri-haskell-0.1.0.0: build (lib + exe)
Preprocessing library ehri-haskell-0.1.0.0...
Preprocessing executable 'ehri-haskell-exe' for ehri-haskell-0.1.0.0...
ehri-haskell-0.1.0.0: copy/register
Installing library in
/mnt/docs/RubymineProjects/ehri-haskell/.stack-work/install/x86_64-linux/lts-8.6/8.0.2/lib/x86_64-linux-ghc-8.0.2/ehri-haskell-0.1.0.0-Kh3VLZPfbij7EgcL22QBMN
Installing executable(s) in
/mnt/docs/RubymineProjects/ehri-haskell/.stack-work/install/x86_64-linux/lts-8.6/8.0.2/bin
/mnt/docs/RubymineProjects/ehri-haskell/.stack-work/install/x86_64-linux/lts-8.6/8.0.2/bin/.copyFile5965166491189641421.tmp:
copyFile: does not exist (Host is down)
'cabal copy' failed. Error message:
-- While building package ehri-haskell-0.1.0.0 using:
/root/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.2.0 copy
Process exited with code: ExitFailure 1
One possible cause of this issue is:
* No module named "Main". The 'main-is' source file should usually have a header indicating that it's a 'Main' module.
# stack --version
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0
Looks like the issue is caused by the depth of the folder where the project lives (Windows 10, x64). From the moment the depth exceeds some threshold, described error appears. So try moving the project folder up in directories tree.
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.
Steps to reproduce:
$ stack new profiling-test
$ cd profiling-test
$ stack build --profile
A new project is initialized with lts-7.2 and a default template. I get the error:
While constructing the BuildPlan the following exceptions were encountered:
-- While attempting to add dependency,
Could not find package base in known packages
-- Failure when adding dependencies:
base: needed (>=4.7 && <5), stack configuration has no specified version (latest applicable is 4.9.0.0)
needed for package profiling-test-0.1.0.0
Recommended action: try adding the following to your extra-deps in ~/profiling-test/stack.yaml
- base-4.9.0.0
You may also want to try the 'stack solver' command
If I just do stack build, it compiles fine without any errors.
I've added base-4.9.0.0 to extra-deps in stack.yaml, but I get the same error.
My stack version is:
$ stack --version
Version 1.1.3, Git revision 225df244ea346a8dc880ef911b002583486a92b2 x86_64 hpack-0.14.0
And I'm running Ubuntu 14.04 trusty.
Thanks in advance for any help!
Figured it out after finding https://github.com/commercialhaskell/stack/issues/1331.
Solution:
Instead of doing
$ stack build --profile
Do:
$ stack build --profile --no-system-ghc
And just add --no-system-ghc to everything. You might potentially need to do stack setup --no-system-ghc before everything too?
Alternatively, as suggested by the comments, you can add this to the stack.yaml for the project or for your global stack project.
When building threepenny-gui on NixOS with stack --nix build, I got error saying I have the wrong version of ghc. Then I tried stack --nix setup, which doesn't run because bash is on an unexpected path on NixOS (that's expected, since the stack documentation only mentions stack --nix build not setup). What am I missing?
FYI, to deal with the zlib issues I have also added a shell.nix and default.nix per https://github.com/commercialhaskell/stack/issues/2130
EDIT: was able to build with the method suggested by mkkeankylej from the above link, i.e. editing ~/.stack/config.yaml and add zlib to buildInputs in shell.nix But I'd still like to know if there's a way to do it w/o falling back to nix-shell? It sounds like stack --nix build should work as long as the nix-shell method does.
First of all, threepenny-gui seems to provide no stack.yaml, i.e. the project isn't configured to be built with stack. Thus, I wonder why you even bother using stack since that is not going to be any easier than building the project with cabal-install or even Nix directly. The easiest and fastest way is probably to configure the build by running:
$ nix-shell "<nixpkgs>" -A haskellPackages.threepenny-gui.env --run "cabal configure"
Afterwards, you can simply "cabal build" the project and work with it (inside or outside of a nix-shell) as you please; the compiler and all necessary build dependencies are provided by Nix.
If you don't want that, then you can use the normal cabal-install approach:
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal configure
$ cabal build
That build is probably going to require system libraries, like libz, so you must make sure that those are available. There's a million different ways to accomplish that, but the cleanest IMHO is the following:
$ zlibinc=$(nix-build --no-out-link "<nixpkgs>" -A zlib.dev)
$ zliblib=$(nix-build --no-out-link "<nixpkgs>" -A zlib.out)
$ cabal install --only-dependencies --extra-include-dirs=$zlibinc --extra-lib-dirs=$zliblib
Last but not least, it's not obvious to me why your stack build --nix command won't succeed, because that command will use Nix to install the proper version of GHC automatically. So if that doesn't work, then my best guess is that you're using an old version of stack where that feature doesn't work properly. I've tried that build using the stack binary that Nix provides, stack 1.3.2, and it can compile a current git checkout of threepenny-gui just fine:
$ git clone git://github.com/HeinrichApfelmus/threepenny-gui.git
Cloning into 'threepenny-gui'...
remote: Counting objects: 4102, done.
remote: Total 4102 (delta 0), reused 0 (delta 0), pack-reused 4101
Receiving objects: 100% (4102/4102), 1.88 MiB | 581.00 KiB/s, done.
Resolving deltas: 100% (2290/2290), done.
$ cd threepenny-gui
$ stack init
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- threepenny-gui.cabal
Selecting the best among 9 snapshots...
* Partially matches lts-7.16
websockets-snap not found
- threepenny-gui requires >=0.8 && <0.11
Using package flags:
- threepenny-gui: buildexamples = False, network-uri = True, rebug = False
* Matches nightly-2017-01-17
Selected resolver: nightly-2017-01-17
Initialising configuration using resolver: nightly-2017-01-17
Total number of user packages considered: 1
Writing configuration to file: stack.yaml
All done.
$ stack build --nix --nix-packages zlib
threepenny-gui-0.7.1.0: configure (lib)
Configuring threepenny-gui-0.7.1.0...
threepenny-gui-0.7.1.0: build (lib)
Preprocessing library threepenny-gui-0.7.1.0...
[...]
Registering threepenny-gui-0.7.1.0...
This works without any specially edited config files for nix-shell, nor does it require special customization of stack.