stack build doesn't work without explicit package name (imprecise docs?)

[kgadek]

Steps to reproduce:

1. mkdir -p aa/src build
2. echo 'main = putStrLn "aa"' > aa/src/Main.hs
3. use build/stack.yaml as shown below
4. cd build && stack build

build/stack.yaml:

extra-deps: []
flags: {}
packages:
- ../aa
resolver: lts-2.15

Expected:

As mentioned in stack build --help, I expected the stack to build aa:

Available options:
TARGET If none specified, use all packages defined in current directory

Actual:

No output, only build/.stack-work created.

Here is the stack ---version output:

$ stack --version
Version 0.1.1.0, Git revision 91fe70306f51eb3d68667a0d6e09a7d7ebbeb2b6

Here is the command I ran with --verbose:

$ stack build --verbose
Version 0.1.1.0, Git revision 91fe70306f51eb3d68667a0d6e09a7d7ebbeb2b6
2015-07-02 22:01:11.255768: [debug] Checking for project config at: /Users/konrad/tmp/stack_01/build/stack.yaml @(stack-0.1.1.0:Stack.Config src/Stack/Config.hs:489:9)
2015-07-02 22:01:11.256538: [debug] Loading project config file stack.yaml @(stack-0.1.1.0:Stack.Config src/Stack/Config.hs:512:13)
2015-07-02 22:01:11.26431: [debug] Run process: ghc --info @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:11.332144: [debug] Run process: ghc --numeric-version @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:11.365811: [debug] Run process: ghc-pkg --no-user-package-db field --simple-output Cabal id @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:11.392331: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:11.41815: [debug] Checking resolver: lts-2.15 @(stack-0.1.1.0:Stack.Build.Source src/Stack/Build/Source.hs:76:13)
2015-07-02 22:01:11.66469: [debug] Run process: ghc-pkg --global --no-user-package-db dump --expand-pkgroot @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:11.710385: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/konrad/.stack/snapshots/x86_64-osx/lts-2.15/7.8.4/pkgdb/ dump --expand-pkgroot @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:11.754539: [debug] Run process: ghc-pkg --user --no-user-package-db --package-db /Users/konrad/tmp/stack_01/build/.stack-work/install/x86_64-osx/lts-2.15/7.8.4/pkgdb/ dump --expand-pkgroot @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)
2015-07-02 22:01:12.165679: [debug] Run process: ghc-pkg --no-user-package-db list --global @(stack-0.1.1.0:System.Process.Read src/System/Process/Read.hs:253:3)

However…

When calling explicitly, it all seems to work:

$ stack build aa
aa-0.1.0.0: configure
Configuring aa-0.1.0.0...
Warning: The 'license-file' field refers to the file 'LICENSE' which does not
exist.
aa-0.1.0.0: build
Building aa-0.1.0.0...
Preprocessing executable 'tmp' for aa-0.1.0.0...
[1 of 1] Compiling Main             ( src/Main.hs, .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/tmp/tmp-tmp/Main.o )
Linking .stack-work/dist/x86_64-osx/Cabal-1.18.1.5/build/tmp/tmp ...
aa-0.1.0.0: install
Setup.hs: LICENSE: does not exist

--  While building package aa-0.1.0.0 using:
      /Users/konrad/.ghc-current/bin/runhaskell -package=Cabal-1.18.1.5 -clear-package-db -global-package-db -package-db=/Users/konrad/.stack/snapshots/x86_64-osx/lts-2.15/7.8.4/pkgdb/ /var/folders/ht/r6kkmd8s467c4hwqbbpvymxh0000gp/T/stack86821/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.18.1.5/ install
    Process exited with code: ExitFailure 1

[snoyberg]

Thanks for the report. I think this is a duplicate of #366.

[snoyberg]

Alright, we're currently in a clear "no way to win 'em all" situation. This seems like a direct duplicate of #366, meaning at least two people thought the old behavior was unintuitive. The new behavior is now implemented which is "if no targets are given, build all targets." This however is contradicted by #552, which preferred the old behavior.

I don't have a horse in this race, but we need to come up with a solution, and document it in the FAQ. I'm leaning towards the old behavior, as it seems like it overall confused people less.

For the record, the following two incantations should be sufficient to overriding the default:

• stack build . to only build the current package
• stack build / to build everything

Pinging @DanBurton @drwebb @manny-fp, who I believe all expressed interest in this. Let's make a decision in the next day or two.

[chrisdone]

I see three possible approaches:

1. If we go with the old logic, we could have: if the pwd = the root, build literally all targets including ones outside the root, because that's as high up in the hierarchy one can go (this is sort of what I had in mind when writing the Targets outside of root dir don't build #366 ticket). I think considered alone, that makes sense, to build everything when in the root. Then when cd'ing into a, building only a also makes sense. The con there is that you can't build just the targets within the stack.yaml root, as opposed to what are presumably third-party things outside the root.
2. Old behaviour plus --all might be an easier compromise, that would handle the rarer use-case of having things outside the root (especially in the docker scenario) while leaving the more usual case of cd x; stack build working as expected.
3. If we go with the new logic, the analogy can be made to make where specifying the target is more usual. stack build would mean "do everything" and stack build . would mean "just this target" and should be documented because it isn't obvious.

I'm leaning towards (2).

[kgadek]

The stack build / looks a bit like "build everything on your hard-disk". I like the stack build ., the semantics is clear as it resembles the '.' entry.

As for me, the 3rd option (the new behaviour) by @chrisdone looks most natural. Rationale:

• I don't really care where are the sources, since if I had put something in the packages section in yaml file that means that I want it built;
• I don't see the reason to expose the difference in semantics for out-of-root packages to the user — what are the benefits?
• 3rd also appears most similar to other build systems; e.g. cmake that strongly promotes out-of-source builds: they make few things easier (cleaning, having old build artefacts archived, clean separation of artefacts from sources)

I don't like the 1st — behaviour depending on the pwd = the root condition — since to know what happens user would have to understand where in the packages hierarchy he is. I assume that could not always be obvious.

[drwebb]

My votes:

1. -1, I want to be able to build targets individually
2. • 0.25
3. • 1, I like the build everything by default, it feels the most natural to me

[snoyberg]

Alright, we're going with the new logic as per (3) above.

[kgadek]

Isn't there any work to be done here? It is still the case that stack build does not build everything on Version 0.1.2.0, Git revision 65246552936b7da4b64b38372feac903d96a8911 on OS X.

[snoyberg]

Can you try the latest master?

[kgadek]

Oh yes, it works well on Version 0.1.2.1, Git revision c5b98565e0401453ba3c86c01a41db64dff5b69c 👍

[jcpetruzza]

Will the logic (3) also apply to stack clean? (#583) I'd argue it would be the wrong default in that case: if I run stack clean inside a package, I prefer only that target to be cleaned instead of having to wait for the whole build afterwards only because I forgot to type a .

I'd actually suggest to use (2) consistently on every command

[kgadek]

Actually I'd be fine with the (3) for stack clean.