Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack build copies unnecessary executables when asked to build just a single executable #3486

Closed
athas opened this issue Oct 12, 2017 · 5 comments
Milestone

Comments

@athas
Copy link

athas commented Oct 12, 2017

General summary/comments (optional)

Steps to reproduce

  1. Have a repository with several executable targets. Say, the project is foo, and the executables are exe1, exe2, exe3.
  2. Run stack build foo:exe3

Expected

Stack should build the exe3 target (and any dirty dependencies) and then only copy the exe3 binary from the .stack-work/dist/.../build/ directory to .stack-work/install/.../bin/.

Actual

Stack copies all executables in the package, even the ones with no changes and which it was not asked to copy, which is slow if there are a lot of them.

Stack version

$ stack --version
Version 1.5.1, Git revision 96e83a05fbeafb5cc3b1f52195433101c1f6ab8a x86_64 hpack-0.18.1

Method of installation

Via stack upgrade.

@mgsloan
Copy link
Contributor

mgsloan commented Oct 15, 2017

This is a symptom of #1406 , which at its root is a cabal issue. It seemed like this was going to get fixed in cabal, there was even a PR, but it got left out of releases for some reason.

Worth revisiting. For now, you'll have to live with it. One option is to add cabal flags to set buildable: false on particular executables.

@mgsloan mgsloan added this to the Support milestone Oct 15, 2017
@23Skidoo
Copy link

This is a symptom of #1406 , which at its root is a cabal issue. It seemed like this was going to get fixed in cabal, there was even a PR, but it got left out of releases for some reason.

Can someone please summarise the issue and post a ticket to the Cabal bug tracker (or post a comment in an existing thread, if there's already a ticket)?

@mgsloan
Copy link
Contributor

mgsloan commented Dec 14, 2017

@23Skidoo Sorry for the delay on following up on this. I've opened #3653 to track looking into whether this is resolved in Cabal-2.0, and changing how things work if it does. If not, an issue will be opened to track it.

EDIT: I realized there was already an issue, and indeed it is not fixed in Cabal-2.0 haskell/cabal#2780

@mgsloan
Copy link
Contributor

mgsloan commented Dec 29, 2017

Based on ezyang's comment in haskell/cabal#2780 (comment) , it should be feasible to move forward on this at least when Cabal >= 2.0

@mpilgrem
Copy link
Member

I am closing this issue as fixed in #6451

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants