Component target syntax for a single executable builds all executables instead of the targeted one.

[recursion-ninja]

me@box:~$ stack --version
Version 1.3.2

I have a .cabal with one library and 3 executables defined in it. Without loss of generality, let's name the library libraryName and the three executables executableOne, executableTwo, and executableThree.

Let's say that libraryName, executableOne and executableTwo type check but executableThree fails to type check.

I ran all of the following:

stack build :executableOne
stack build libraryName:executableOne
stack build libraryName:exe:executableOne

On each run stack attempted to build the library and all three executables.

• executableOne build successfully, great that's what I asked for.
• executableTwo build successfully, not what I asked from but no harm no foul.
• executableThree failed to build, and executableOne and executableTwo both were not installed because executableThree failed to build.

What I expected to happen:

• executableOne build to successfully.
• executableTwo not attempted to be built even though it could be built successfully.
• executableThree not attempted to be built because it could be built successfully.
• executableOne to be installed because it built successfully and other failing builds were not attempted.

According to the documentation on components and on target syntax this is not the expected behavior.

Isn't the whole use case for this feature to build certain explicit components of a project when other components won't build? Seems to be failing.

[recursion-ninja]

Here's an example project to reproduce the error.

Reproduce with:
stack build :target-executable

[sjakobi]

Looks like a duplicate of #1406.

[recursion-ninja]

Maybe they should remove this feature from the documentation until it's been reimplemented. Accoring to the other issue referenced by @sjakobi, it has been over a year since this feature worked.

[mgsloan]

Indeed, closing as a duplicate. I agree that it sucks, unfortunately we are blocked on Cabal here. Despite haskell/cabal#3022 getting merged more than a year ago, it hasn't made it into a released version of Cabal.

I've added a note to the docs about this, good idea.